2010-01-14 11 views
11

Estoy tratando de encontrar información sobre los límites de datos relacionados con stdout en Windows. Parece que no puedo encontrar la información en MSDN.¿Hay un tamaño de búfer asociado a stdout?

  1. ¿Existe un límite en la cantidad de datos que pueden escribirse en stdout? Si es así, ¿qué sucede si se alcanza el límite? ¿Se pierde la información?

  2. Si se redirige stdout (por ejemplo, al iniciar el proceso desde .Net y utilizando la propiedad ProcessStartInfo.RedirectStandardOutput), ¿tiene algún efecto sobre la cantidad de datos que se pueden escribir? A medida que leo de la secuencia estándar en el proceso de llamada, ¿eso afecta las limitaciones?

  3. ¿Están estos límites relacionados de alguna manera con las canalizaciones con nombre?

Respuesta

19

Depende dónde se va - pero eso sí, si se redirecciona la salida en .NET se puede ejecutar fácilmente en problemas si usted no lee la salida. Cuando se agote el búfer, se escribirá en stdout en el proceso hijo se bloqueará. Una causa común de estancamiento es un proceso "padre" que espera que el "niño" salga, y luego lee el resultado; eso no funcionará si el niño necesita que el padre lea el resultado para liberar espacio en el búfer.

.NET ha hecho esto un poco más fácil al permitir un enfoque basado en eventos con Process.OutputDataReceived y Process.ErrorDataReceived. Esto significa que no es necesario para empezar a dos hilos (uno para leer la salida estándar, que uno lea stderr) sólo para mantener el proceso de bloqueo ...

+1

Eso es mucho más útil que lo que publiqué. Borrando mi propio anuncio publicitario, votando por ti. – David

+0

Ahora que es una característica útil. Me pregunto si Java agregará algo así algún día. –

+0

(+1) Probablemente sea mucho más útil tener la perspectiva de .NET, ya que estoy seguro de que las decisiones tomadas son para simplificar las cosas para el programador, aunque stdout es bastante simple (por defecto) en C también. –

3

Algunas cosas a tener en cuenta:

1) Jon es correcto: si se alcanza el límite del búfer, la llamada de escritura en su subproceso se bloqueará. Debe drenar el flujo de stdout si no se lo redirecciona a un lugar que lo hará drenar automáticamente, como un archivo. Las tuberías deben ser drenadas, y generalmente, si puede "conectar" a una salida de subproceso, se está conectando a una tubería.

2) La E/S a un flujo de salida es probablemente tamponada, lo que significa que si el subproceso escribe alguna información a la salida estándar sin llamar explícitamente flush(), que es casi siempre el caso, usted no puede ver la salida. Se llama automáticamente a la descarga cuando el proceso sale, por lo que si se trata de un pequeño subproceso pequeño, debería estar bien, pero si no es así, no hay manera de forzar su salida para que aparezca cuando lo desee.

3) Las tuberías con nombre son esencialmente un búfer que el sistema operativo mantiene que se pueden escribir y leer, es decir, son como un archivo que puede escribir en un proceso y leer en otro, sin tener realmente la sobrecarga de tener un archivo en el disco. Muy útil para la comunicación entre procesos, pero todas las limitaciones de E/S con almacenamiento en búfer/búferes completos aún se aplican.

3

stdout tiene un búfer de 1024 bytes

+2

¿Tiene alguna fuente para este reclamo? – Zero3

Cuestiones relacionadas