Там есть цикл, в котором строки считываются из stdout и stderr поочерёдно.
Мне это кажется ошибкой, так как есть же в рантайме c привязка/синхронизация между выводом в stderr и stdout. Т.е. автор программы выводит сообщения в одном порядке, а этот фрагмент вывод будет перемешивать в другом порядке.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Мне это кажется ошибкой, так как есть же в рантайме c привязка/синхронизация между выводом в stderr и stdout. Т.е. автор программы выводит сообщения в одном порядке, а этот фрагмент вывод будет перемешивать в другом порядке.
stdout и stderr — это 2 разных файловых потока, со всем из этого вытекающим. Открыв оба, можно читать из каждого независимо. Аналогично тому, что можно читать независимо из двух потоков, открытых на разные файлы.
Кстати, под спудом тут файлы и лежат (точнее, пайпы)
PD> stdout и stderr — это 2 разных файловых потока
Зато когда создаётся виртуальный терминал, у него там всего два handle — один для ввода и один для вывода.
Это означает, что stdout и stderr оба помещаются в один поток в определённом порядке, а этот код этот порядок ломает.
Т.е. в настоящей консоли сообщения будут в одном порядке,
а при обработке этой программой — в другом. И от этого нежелательного эффекта хотелось бы избавится.
Здравствуйте, Эйнсток Файр, Вы писали:
PD>> stdout и stderr — это 2 разных файловых потока
ЭФ>Зато когда создаётся виртуальный терминал, у него там всего два handle — один для ввода и один для вывода. ЭФ>Это означает, что stdout и stderr оба помещаются в один поток в определённом порядке, а этот код этот порядок ломает.
ЭФ>Т.е. в настоящей консоли сообщения будут в одном порядке, ЭФ>а при обработке этой программой — в другом. И от этого нежелательного эффекта хотелось бы избавится.
Если это так, значит, в терминале вызывается прямо или косвенно freopen
PD>Если это так, значит, в терминале вызывается прямо или косвенно freopen
Не очень понял, при чём тут freopen, и при чем тут программа "терминал", ведь обе они ошибку в коде в обсуждаемом фрагменте C# не исправят.
Итак, есть два сценария:
1) создаётся терминал, в нем запускается bash, он запускает прикладную программу, прикладная программа выводит в stdout и stderr
при этом stderr и stdout физически попадают в один "канал" в той последовательности, как их выводит прикладная программа
2) программа на C# запускает прикладную программу, прикладная программа выводит в stdout и stderr
при этом программа на C# чередует строчки из stderr и stdout так как ей нравится.
Тот факт, что где-то в терминале было что-то вызвано никак не влияет на то, что программа на C# написана криво.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>1) создаётся терминал, в нем запускается bash, он запускает прикладную программу, прикладная программа выводит в stdout и stderr ЭФ> при этом stderr и stdout физически попадают в один "канал" в той последовательности, как их выводит прикладная программа
Вполне возможно, что эта прикладная программа переназначила все на один поток.
ЭФ>2) программа на C# запускает прикладную программу, прикладная программа выводит в stdout и stderr ЭФ> при этом программа на C# чередует строчки из stderr и stdout так как ей нравится.
ЭФ>Тот факт, что где-то в терминале было что-то вызвано никак не влияет на то, что программа на C# написана криво.
Она просто читает в предположении. что это разные потоки, вот и все. В общем случае это верно.
Здравствуйте, Эйнсток Файр, Вы писали:
PD>> Она просто читает в предположении. что это разные потоки, вот и все. В общем случае это верно.
ЭФ>Это просто упрощающее предположение. Неправильное. Из-за его неправильности потом в реальном мире возникают проблемы у пользователей:
Дело твое. Можешь считать это упрощающим и неправильным предположением, но тем не менее это так.
можно получить хендлы всех трех потоков, то есть файловые хендлы.
А уж когда в Windows дело дошло до родных ее HANDLE — тут начинают действовать известные правила, касающиеся этих хендлов (HANDLE есть неявный указатель на объект ядра, и для каждого HANDLE этот объект ядра свой).
1. Проблема у пользователей есть
2. Проблему нужно решить (мне — для Linux, в Windows для решения проблем есть Microsoft)
3. Без доказательства говорить, что эта проблема проблема неразрешима — голословно.
4. Наличие трёх дескрипторов само-по-себе ничего не доказывает
ЭФ>Т.е. в настоящей консоли сообщения будут в одном порядке, ЭФ>а при обработке этой программой — в другом. И от этого нежелательного эффекта хотелось бы избавится.
А могут оне быть взаимоисключающими, т.е. пишется либо в stderr, либо в stdout? Поэтому их и можно вычитать в одном цикле.
