FreeBSD, MySQL, Perl, bash:периодическая блокировка именованных каналов?

Question

Это странно, и я не уверен, кто на самом деле виноват.

Я делаю какие-то скрипты на FreeBSD (6.2)?который широко использует следующий ***bash ***ism:

do_something <(mysql --skip-column-names -B -e 'select ... from ... where ...;')

...где "do_something - это несколько грубая утилита (на Perl), которая не будет считываться из конвейера.Если я использую обычный файл, он работает нормально.Мой удар скрипт, использующий такие вещи, как exec 4< <(...) с такого рода запросами (следующими циклами вида while read x y z <&4; do ... кажется, никогда не возникало никаких проблем.

Однако Perl (5.8.x), похоже, периодически блокируется (по-видимому, навсегда).Я попытался изменить chomp(my $data = <MYDATA>); с помощью процедуры , которая использовала системный просмотр и я написал несколько тестовых примеров на Python для сравнения.Кажется, что они блокируют гораздо реже, чем идиоматический код Perl, но они все равно иногда это делают.(Код Python, использующий f.read() или os.read(f.fileno()...) кажется, в этом вопросе они ведут себя примерно одинаково).

Я попытался воспроизвести проблему, используя ... <(cat ...) (где я нахожусь кошкаиспользуя обычный файл), и это, похоже, никогда не воспроизводит эту остановку.

Я просмотрел некоторые ktrace/kdump данные ...но я гораздо больше знаком с Linux страйс или даже Солярис ферменная конструкция ...так что я тоже пока не понял, что будет дальше.

Я полагаю, что мы можем в основном исключить Perl, потому что я воспроизвел ту же проблему с помощью Python ...Я не понимаю, каким образом удар возможно, здесь что-то не так (это просто создание именованного канала в /var/tmp/sh-np-xxx и привязать процессы к этому).

Что могло бы mysql оболочка / утилита делает то, что может вызвать это?Я не думаю, что видел это из чего-либо другого (например, кошка или дд).Я не тестировал этот сценарий под Linux..., но я использовал <(...) (замена процесса) уже много лет работает под Linux и не припоминаю, чтобы когда-либо видел это.

Это проблема с FreeBSD?

Конечно, я могу обойти проблему, используя временные файлы...но я, конечно, предпочел бы понять, почему он это делает (и избежать некоторых гонок и беспорядка при очистке, которые влекут за собой временные файлы).

Есть какие-нибудь предложения?

Answer 1

Большая разница между работой с выводом mysql и непосредственно с файлом заключается во времени.Когда процесс perl останавливается, возникает большой вопрос:"почему это не продвигается вперед"?Вы можете использовать опцию "l" для ps, чтобы увидеть канал ожидания для процесса perl;таким образом, вы можете увидеть, заблокирован ли он при чтении или происходит что-то еще.Если он действительно заблокирован при вводе канала, я ожидаю, что запись MWCHAN для perl будет "piperd".

Та же информация была бы интересна и для процесса mysql.

Как выглядит ваш тестовый код на Python?

Другой способ написать это, избегая при этом башизма, заключается в следующем;это позволило бы вам исключить bash:

mysql --skip-column-names -B -e 'select ... from ... where ...;' | do_something /dev/stdin

Другие интересные вопросы:

• Меняет ли что-нибудь параметр --unbuffered для mysql?

• Меняет ли что-нибудь передача выходных данных mysql через dd?(например."perlscript <(mysql ...| дд)

Краткие сведения:Нужно больше информации.