LINUX.ORG.RU

Асихнронное чтение named pipes

 


0

2

Приветствую. Пытаюсь освоить pipes в баше. Дело такое: создаю named-пайп, запускаю демон, который пишет в этот пайп периодически, когда ему вздумается (включая stderr):

mkfifo npipe
some_daemon 1> npipe 2>&1
А так же создаю фоновый процесс, который читает пайпы и выводит на экран для теста построчно:
bg_proc () {
  while read LINE; do
    echo "---$LINE---"
  done < npipe
}
bg_proc &
Всё вроде бы ничего, пайпы пишутся, выводятся в духе:
---message from daemon #1---
---message from daemon #2---
---message from daemon #3---
Но иногда, видимо когда демон отправляет сообщения слишком быстро — возникает конфликт, и получается что-то в духе:
---message fmessage daemon #2---
После чего никакие дальнейшие сообщения от демона не доходят. Что я упустил, и как решать конфликт? Заранее благодарю!



Последнее исправление: cetjs2 (всего исправлений: 2)

tail -f

Также, никогда не отправляй в фон команды, выводящие что-то на консоль, получишь нечитаемую кашу.

schizoid ★★★
()
Последнее исправление: schizoid (всего исправлений: 1)
Ответ на: комментарий от visual

Проприетарщина, на яве, вполне возможно что использует, а это важно? Ведь просто вывод демона в порядке, проблемы только с пайпами.

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

С coproc никогда раньше дел не имел, гуглил-гуглил. Запустил процесс через

coproc some_daemon
он как положено вернул свой pid, но на команды cosend и coreceive баш ругается: команда мол не найдена (Fedora 19), манов у меня в системе по команде тоже нет, смотрел тут: http://www.unix.com/man-page/all/1f/coproc/

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

Да, но ведь при переполнении этих 4-ёх КиБ оно просто ждёт пока «чтец» не начнёт читать данные, чтобы освободить это место, а как видно по моему примеру — попытка чтения у меня непрерывная, цикличная. Я тестировал и так:

bg_proc () {
  while read LINE; do
    echo "---$LINE---"
  done < npipe
  echo "THE END"
}
bg_proc &
И “THE END” я не вижу, покуда не оборву выполнение чрез Ctrl+C, а точнее — покуда не ляжет демон, который пишет свой «выхлоп» в пайп. То-есть ожидание данных на чтение имеется.

Плюс FIFO позиционируется как “First In — First Out”, а тут получается одна из записей вклинивается и всё ломается, часть от старой записи, часть от другой и дальше процесс остановлен, непонятно чем, а точнее сказать — заморожен, потому что чтение продолжается, просто провисает в ожидании.

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

Мне пока непонятен камень преткновения с многотридностью демона, когда разные триды пишут в stdout, если бы были конфликты, про которые я описал (когда одно влезает поверх предыдущего), то по моим логическим представлениям, то же самое бы творилось и с обычным, не перехваченным выводом в терминал, но этого не происходит. Единственное предположение, на этот счёт, что переполняются тех самых 4кб, но демон не впадает в ожидание доступности записи, а продолжает пытаться слать на stdout данные, игнорируя невозможность писать, хотя это и не совсем в общую картину клеится, но хоть как-то объясняет суть проблемы мне, быть может версия хотябы приблизительно истинная.

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

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

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

я думаю проблема в том что вывод не флашится из явы

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

Наркоман, штоле? Зачем тебе read line? Почитай маны.

schizoid ★★★
()

Я извиняюсь, в реальном месте не заметил, что сделал следующее:

mkfifo npipe
some_daemon 1> npipe 2>&1

bg_proc () {
  cat npipe | while read LINE; do
    echo "---$LINE---"
  done
}
cat npipe | bg_proc &
Убрал «cat npipe |» с последней строки, проблема вроде исчезла.

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