LINUX.ORG.RU

увеличить размер fifo?


0

0

Делаю mkfifo <файл>

Потом начинаю в него писать и читать.

Опытным путем выяснено, что больше чем 64К записать невозможно - в неблокирующем режиме вываливается "Resource temporarily unavailable", в блокирующем - ждет, пока на том конце не прочитают.

Можно ли увеличить этот ограничение?

ulimit говорит unlimited, где еще какие ограничения могут быть?

Размер буфера мне нужно поднять до нескольких мегабайт (8-32), как минимум. Это возможно вообще?

Можно, конечно, мониторить select'ом, пока буфер не освободится, но хочется более простого решения.

★★★★★

заюзай в промежутке (перед fifo) программу buffer

mkfifo fifo1 
app1 | buffer --size=8M > fifo1


$ apt-cache show buffer | awk '/Description:/ {f=1}; /Tag:/ {exit}; f'
Description: Buffering/reblocking program for tape backups, printing, etc.
 Buffer implements double buffering and can be used to keep backup tapes
 streaming or printers printing. It can also be used to convert a data
 stream to a given output blocksize.
 .
 Buffer uses shared memory to convert a variable input data rate to a
 constant output data rate. It is typically used in a pipe between a backup
 program and the tape device, but there are also other applications like
 buffering printer data in lpd's input filter.

sdio ★★★★★
()
Ответ на: комментарий от sdio

Это мне не сильно поможет. Из python это не сильно удобно будет юзать, да и ловить ошибки при переполнении буфера у buffer будет дополнительным геморроем...

Видимо, с select'ом буду врапперов мастерить...

AngryElf ★★★★★
() автор топика

в *bsd это параметр компиляции ядра. В линуксе наверно тоже..

dilmah ★★★★★
()

ИМХО если встала подобная проблема -- что-то не то в дизайне. Конечно, можно гланды и автогеном...

> Можно, конечно, мониторить select'ом, пока буфер не освободится,...

ИМХО не можно, а нужно

>... но хочется более простого решения.

Это и есть простое решение!

Если есть желание писАть (без читателя) в FIFO мегабайты, значит, это не про ПОЗИКС. По идее, пайп без читателя вообще должен блокироваться при попытке записи.

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

Читатель есть, просто за небольшой промежуток времени один процесс должен записать большой промежуток данных в пайпы и отвалить в спячку. И в случае короткого буфера он будет до потери пульса ждать, когда ж, наконец, проснется читатель и вычитает ему причитающееся.

А хочется что б больше времени проводилось в обработке данных, а не в ожидании их передачи...

Дизайн - возможно, третий раз уже переписывать это буду... :)

Суть системы - имеется несколько процессов (нафорканных), которые по цепочке гонят данные и обрабатывают их по ходу. Вот только цепочка может размножаться - данные всегда приходят с одного источника и уходят на 1 или несколько. В качестве промежуточного места хранения вначале юзал SysV IPC, но запарился отлавливать случайные глюки.. Теперь ищу что-нить более простое.

Обработка идет разными кусками. Каким-то модулям хватает 8кб для работы, каким-то 200-500кб мало. Т.е. поток и вычитывание неравномерное. Опытным путем установлены размеры буферов начиная с нескольких мегабайт. Тут-то и пришел затык в виде ограничений FIFO.

AngryElf ★★★★★
() автор топика
Ответ на: комментарий от Legioner

У меня этих тредов уже и так с десяток в базовой конфигурации будет. И еще десяток на буферизацию... ХЗ, видимо, так и придется делать...

AngryElf ★★★★★
() автор топика
Ответ на: комментарий от AngryElf

AngryElf: > ...за небольшой промежуток времени один процесс должен записать большой промежуток данных в пайпы и отвалить в спячку.

Это я и имел в виду -- именно для подобных ситуаций люди придумали файлы...

"Пайп" в переводе означает "труба", а не "резервуар"!

Сделай тупой резервуар в промежутке, если переделывать всю логику долго. Пусть он состоит из двух ниток, одна читает данные из пайпа и складывает их в FIFO, вторая оттуда данные забирает и скидывает их в дружественный пайп.

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

> "Пайп" в переводе означает "труба", а не "резервуар"!

Длинная труба становится и резервуаром :-)

Спасибо всем, вектор пинка стабилизировался.

AngryElf ★★★★★
() автор топика
Ответ на: комментарий от klalafuda

Да-да, я после постинга тоже об этом подумал :-)

AngryElf ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.