windows 是否有附加到 stdout 的缓冲区大小？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2066242/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is there a buffer size attached to stdout?
提问by jameswelle
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.
我正在尝试查找与 Windows 上的 stdout 相关的数据限制的一些信息。我似乎无法在 MSDN 上找到信息。
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?
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?
Are these limits related in any way to named pipes?
可以将多少数据写入标准输出是否有限制？如果是这样，如果达到限制会发生什么？数据丢失了吗？
如果标准输出被重定向（例如，通过从 .Net 启动进程并使用 ProcessStartInfo.RedirectStandardOutput 属性），这对可以写入的数据量有任何影响吗？当我从调用过程中的 stdout 流中读取时，这会影响限制吗？
这些限制与命名管道有任何关系吗？
回答by Jon Skeet
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 中重定向输出，如果您不读取输出，则很容易遇到问题。当缓冲区用完时，对子进程中的 stdout 的写入将被阻塞。死锁的一个常见原因是“父”进程等待“子”退出，然后读取输出 - 如果子需要父读取输出以释放缓冲区空间，这将不起作用。
.NET has made this slightly easier by allowing an event-driven approach with Process.OutputDataReceivedand 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...
.NET 通过允许使用Process.OutputDataReceived和的事件驱动方法使这变得稍微容易一些Process.ErrorDataReceived。这意味着您不需要启动两个线程（一个用于读取 stdout，一个用于读取 stderr）只是为了防止进程阻塞...
回答by Matt
Some things to keep in mind:
要记住的一些事情：
1) Jon is right - if the buffer limit is reached, the write call in your subprocess will block. You need to drain the stdout stream if it is not being redirected somewhere that will cause it to automatically drain - like a file. Pipes need to be drained, and usually, if you can "attach" to a subprocess' output, you're attaching to a pipe.
1) Jon 是对的 - 如果达到缓冲区限制，子进程中的写入调用将被阻塞。如果标准输出流没有被重定向到会导致它自动排空的地方——就像一个文件一样，你需要排空标准输出流。管道需要排空，通常，如果您可以“附加”到子进程的输出，那么您就是在附加到管道。
2) The I/O to an output stream is probablybuffered, which means that if the subprocess writes some information to stdout without explicitly calling flush(), which is almost always the case, you might not see the output. Flush is automatically called when the process exits, so if it's a short small subprocess you should be OK, but if it's not, you have no real way of forcing its output to show up when you want it to.
2) 输出流的 I/O可能被缓冲，这意味着如果子进程在没有显式调用flush()的情况下将一些信息写入 stdout （几乎总是这种情况），您可能看不到输出。当进程退出时会自动调用 Flush，所以如果它是一个简短的小子进程，你应该没问题，但如果不是，你就没有真正的方法来强制它的输出在你想要的时候显示出来。
3) Named pipes are essentially a buffer that the OS maintains that can be written to and read from - that is, they're like a file you can write to from one process and read from in another, without actually having the overhead of having a file on disk. Very handy for communication between processes, but all the I/O limitations with buffering / full buffers still apply.
3）命名管道本质上是操作系统维护的缓冲区，可以写入和读取 - 也就是说，它们就像一个文件，您可以从一个进程写入并从另一个进程读取，而实际上没有开销磁盘上的一个文件。对于进程之间的通信非常方便，但缓冲/满缓冲区的所有 I/O 限制仍然适用。
回答by FSD
stdout has a buffer of 1024 bytes
stdout 有一个 1024 字节的缓冲区
