Хе-хе, баг в редхатовской реализации FIFO? (+)

Добавление оттуда же -- глюк наблюдается в 9-ке, в 8-ке все нормально. А как в федоре?

>А как в федоре?

456123

На опеннете смотрю совсем ламеры живут... зачем оба echo в бекграунде запускать? у вас в общем случае получается гонка, два работающих процесса, и результат записи не определен (смешивается). можно сэмулировать эту ситуацию, если в момент запуска первого процесса система была сильно загружена, и, скажем, свалила его в своп. пока она его будет оттуда доставать, второй уже запишет 456. уберите амперсанды и убедитесь, что будет 123456 везде.

Тогда почему эта гонка проявляется ТОЛЬКО после 9-го редхата (в восьмерке-то все нормально)? Почему у других указанных систем все как положено?

Не "как положено" а "так получилось". Просто алгоритм планировщика системы делает более (или менее) _вероятным_ один из результатов.

> Тогда почему эта гонка проявляется ТОЛЬКО после 9-го редхата (в восьмерке-то все нормально)? Почему у других указанных систем все как положено?

Я вам еще раз говорю: в данном примере нет понятия "как положено". Это примерно как жаловаться, что строчки из SQL-таблицы выбираются не в порядке занесения. Это как жаловаться, что несколько одновременно пишущих программ в файл почему-то сохраняют туда мусор. Все, что вы наблюдаете - что статистически одна из ситуаций более вероятна на одной системе и менее вероятна на другой. У меня на redhat 7.2 вот тоже 456132 получилось. И на debian 3.0. Короче, вообще не критерий.

Кстати, последнее время в linux были изменения планировщика на более "десктопный" вариант, то есть в уменьшении времени отклика для активных приложений. Редхат, как известно, пионер в протаскивании подобных патчей в ядро. Вполне возможно, что это повлияло на то, что программа, запущенная второй, пробуждается раньше. Это работа шедулера. Формально, обе проги сидят в i/o wait, пока не стартанет читатель из трубы (cat). Приоритет у прог одинаковый. Кто из них стартанет первым и уложит свои данные в трубу - зависит от того, кого из "равных программ" планировщик достанет первым для выполнений. В случае с 456123, очевидно, берется последний из списка. У других систем, вероятно, первый.

Я еще раз хочу подчеркнуть - описанное поведение у _всех_ систем не является ошибочным, потому как в ситуацию заложен race condition. А индивидуальные особенности планировщиков не влияют на правильность работы системы в целом; было бы куда интересней, если бы данные в трубе терялись или удваивались. Если вы хотите предсказуемость в выводе, то вы должны средствами IPC синхронизовать действия пишущих. Или, в простейшем варианте, запускать их последовательно.

Похоже, что не в ядре. На OpenNet заявлено, что "баг" (я специально употребил кавычки) есть в случае применения mkfifo из coreutils, а "правильно" работает в случае mkfifo из fileutils.

ссылку на opennet дай

http://www.opennet.ru/openforum/vsluhforumID1/40374.html

по-моему, они смешивают пакеты и системы. в rh9 нет пакета fileutils. видимо, в случае с fileutils речь идет про rh8. а различия систем мы уже обсудили