> я прочитал что при переполнении буфера
он никак не может переполниться
> НЕ гарантируется атомарность - совсем хорошо
используйте блокировки
что вы собственно хотели? чтобы атомарность была
при любом размере записи? это означает монопольное
использование.
нет, я прочитал следующее:
"при записи большего числа байтов чем это позволяет канал или FIFO, вызов write(2) блокируется до освобождения требуемого места, при этом атомарность операции не гарантируется."
А поскольку когда именно наступит это насыщение не известно, получается
что использовать pipe/fifo вообще не безопастно, поскольку теряется атомарность :(
Что-то я в тупик зашел.
Предпологалось использовать fifo для активного обмена - при этом важна именно атомарность. Сейчас fifo используется в не блокирующем режиме.
> вообще не безопастно, поскольку теряется атомарность :(
я еще раз повторяю, используйте синхронизацию, если
нужна атомарность при записи > 4K.
можете также использовать datagram unix sockets.
> А поскольку когда именно наступит это насыщение не известно, получается что использовать pipe/fifo вообще не безопастно, поскольку теряется атомарность :(
Используй свою собственную буферизацию и будет атомарность. Если ты можешь определить кончился твой атомарный пакет или нет, то ты можешь буферизировать его сам..
Хочешь сказать что я могу отбросить начало пришедшего пакета если я вижу что он пришел не полностью ? Действительно принемающая сторона может это детектировать а отправляющая ? Черт пожалуй отправляющая то-же !
Надо попробывать !
>>Под Юнихом, как и в любых сисемах с разделением времени, сие >>невозможно концептуально.
Атомарность ? Как это не возможна ? В книгах пишут что как раз ГАРАНТИРУЕТСЯ. Типа есть сервер у него открыт fifo ему туда одновременно пишут два процесса. Один пишет 12345 а другой 67890. Дык вот пишут что гарантируется что придет 1234567890 или 6789012345 но не как не их перемешанные данные типа 1627384950.
В чем вообще задача: есть сервер и у него куча клиентов.
У сервера есть открытый fifo куда клиенты кидают пакеты с сообщением о себе и об отрытых ими пайпах связи. Дальше идет интенсивный обмен данными. Сейчас это сделано так: сервер посылает сообщения клиентам по их пайпам, клиенты посылают сообщения серверу по его fifo.
Как я теперь понимаю :) fifo сервера может легко переполнится и сообщения потеряют атомарность. Вероятно я переделаю обмен так что клиенты будут посылать сообщения по открытым ими пайпам, а значит данные не будут перемешиватся. Все равно остается открытым вопрос по аутентификации клиентов на сервере. :(
>>В пределах АТОМА, который, кстати, в Линухе аж 4K.
>>Если ты пишешь в pipe 2Gb текста, то только однопользовательская >>система может тебе гарантировать атомарность.
Вот-вот я именно об этом.
> Хочешь сказать что я могу отбросить начало пришедшего пакета если я вижу что он пришел не полностью ?
Действительно принемающая сторона может это детектировать а отправляющая ? Черт пожалуй
отправляющая то-же ! Надо попробывать !
Похоже, ты чего-то не то делаешь! В смысле, так не делают.
Прокинь еще пайпов, кто мешает? А если нельзя (например, stdin/out надо пользовать),
то задумайся о синхронизации (семафорами, например).
> Все равно остается открытым вопрос по аутентификации клиентов на сервере. :(
может лучше в таком случае использовать unix socket?
сервер его слушает и каждому присоеденившемуся клиенту дается по дескриптору. Затем загоняем все эти дескрипторы в один select.
И вопросы по поводу атомарности отпадут.
Да я к этому и пришел (как написал выше) :)
Остается проблемма аутентификации. Вероятно это нужно делать тоже не по fifo. SYS V очередь сообщений вроде не подходит. Вроде POSIX очередь сообещний подходит. Жаль книжки под рукой нет, дома уточню...
>>Остается проблемма аутентификации.
Если тебя устраивает идентификация -> то есть отличный метод - называется pam.
Если нужна именно аутентификации - kerberos поможет.