You cannot control the size of the buffer. You can pass in read and write buffers from 1 to CreateNamedPipe , but the kernel will automatically increase these buffer sizes. In principle, the buffer will always be at least as large as the largest amount of data that was ready to be read at any given time. In other words, the faster you respond to available data, the fewer blocks of data written to the pipe, the smaller the buffer.
Input and output buffer sizes are recommended. The actual buffer size reserved for each end of the named pipe is either the system default, or the minimum or maximum value of the system, or the specified size, rounded to the next allocation boundary .... Whenever a write operation to the handset occurs, the system first tries to charge the memory from the write quota for the pipe .... If the remaining channel write quota is too small to fulfill the request, the system will try to expand the buffers for data placement using non-payload The pooled pool reserved for the process.
However, I do not think that buffer sizes are really important. Pipes do not delay sending data until the buffer is “full” and nothing is equivalent to the “nagle” option for TCP, so keeping a small buffer size will not improve your delay.
Keep in mind that when you connect the handset to the stdout console application, the output is usually buffered by that application before it is written to the pipe. If you need unbuffered output, you will need to use stderr.
In addition, something to consider when using legacy pipe descriptors is that the spawned application inherits all of your descriptors, so if you have a file or an open socket, you start the application, then close that descriptor, file / socket / etc .. will remain open until the child process is terminated, which can lead to unexpected violations and other strange problems.