Есть ли размер буфера, прикрепленный к stdout?
Я пытаюсь найти некоторую информацию об ограничениях данных, связанных с stdout в Windows. Кажется, я не могу найти информацию о MSDN.
есть ли предел тому, сколько данных можно записать в stdout? Если да, то что произойдет, если предел будет достигнут? Данные потеряны?
Если stdout перенаправляется (например, путем запуска процесса из .Net и с помощью ProcessStartInfo.RedirectStandardOutput свойство), это имеет какое-либо влияние на сколько данных можно записать? Когда я читаю из потока stdout в вызывающем процессе, это влияет на ограничения?
связаны ли эти ограничения каким-либо образом с именованными каналами?
3 ответов
это зависит от того, куда он идет, Но да, если вы перенаправляете вывод в .NET, вы можете легко столкнуться с проблемами, если вы не читаете вывод. Когда буфер закончится, запись в stdout в дочернем процессе будет заблокирована. Одна из распространенных причин взаимоблокировки-это "родительский" процесс, ожидающий выхода "дочернего", а затем считывающий вывод, который не будет работать, если ребенку нужен родитель для чтения вывода, чтобы освободить буферное пространство.
.NET сделал это немного проще, разрешив событийный подход с Process.OutputDataReceived
и Process.ErrorDataReceived
. Это означает, что вам не нужно запускать два потока (один для чтения stdout, один для чтения stderr), чтобы процесс не блокировался...
некоторые вещи, чтобы иметь в виду:
1) Jon прав - если достигнут предел буфера, вызов записи в вашем подпроцессе будет заблокирован. Вам нужно слить поток stdout, если он не перенаправляется куда - то, что заставит его автоматически слить-как файл. Трубы должны быть осушены, и обычно, если вы можете "прикрепиться" к выходу подпроцесса, вы прикрепляетесь к трубе.
2) ввод-вывод в выходной поток наверное buffered, что означает что если подпроцесс записывает некоторую информацию в stdout без явного вызова flush()
, что почти всегда так, вы можете не увидеть вывод. Flush автоматически вызывается при выходе процесса, поэтому, если это короткий небольшой подпроцесс, вы должны быть в порядке, но если это не так, у вас нет реального способа заставить его вывод отображаться, когда вы этого хотите.
3) именованные каналы по существу являются буфером, который поддерживает ОС, который можно записать и прочитать из - То есть, они похожи на файл, в который вы можете писать из одного процесса и читать из другого, фактически не имея накладных расходов на файл на диске. Очень удобно для связи между процессами, но все ограничения ввода-вывода с буферизацией/полными буферами по-прежнему применяются.