有没有附加到标准输出缓冲区的大小？ [英] Is there a buffer size attached to stdout?

问题描述

我试图寻找到标准输出上的Windows相关的数据限制的一些信息。我似乎无法找到MSDN上的信息。

1. 是否有限制多少可以将数据写入到标准输出？如果是这样，如果达到限制会发生什么情况？是数据丢失？

2. 如果标准输出重定向（例如，通过启动从.NET中的过程，并使用ProcessStartInfo.RedirectStandardOutput属性），是否有多少数据可以写什么影响？当我从调用进程的标准输出流中读取，这是否会影响限制？

3. 以任何方式来命名管道相关的这些限制呢？

解决方案

这要看它是怎么回事 - 但是，是的，如果你重定向输出在.NET中，你可以很容易碰到的问题，如果你不读的输出。当缓冲区用完时，写入到标准输出的子进程将阻塞。死锁的一个常见十岁上下的原因是父进程等待孩子退出，然后读取输出 - 如果孩子需要父母来读取输出释放缓冲空间，将无法正常工作<。 / P>

.NET已经被允许与 Process.OutputDataReceived 和 Process.ErrorDataReceived 。这意味着你不需要启动两个线程（一个用于读取标准输出，一个用于读取标准错误），只是为了保持过程阻塞...

I am trying to find some information on data limits related to stdout on Windows. I can't seem to find the information on MSDN.

1. Is there a limit to how much data can be written to stdout? If so, what happens if the limit is reached? Is the data lost?

2. If stdout is redirected (for example, by launching the process from .Net and using the ProcessStartInfo.RedirectStandardOutput property), does that have any effect on how much data can be written? As I read from the stdout stream in the calling process, does that affect the limitations?

3. Are these limits related in any way to named pipes?

解决方案

It depends where it's going - but yes, if you redirect the output in .NET you can easily run into problems if you don't read the output. When the buffer runs out, writes to stdout in the child process will block. One common-ish cause of deadlock is a "parent" process waiting for the "child" to exit, and then reading the output - that won't work if the child needs the parent to read the output to free up buffer space.

.NET has made this slightly easier by allowing an event-driven approach with Process.OutputDataReceived and Process.ErrorDataReceived. This means you don't need to start two threads (one to read stdout, one to read stderr) just to keep the process from blocking...

这篇关于有没有附加到标准输出缓冲区的大小？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！