What you say is either not correct,or you are using confusing terminology.
WriteFile has _no_ buffer associated with it. It gets its data handed to it in an array that is called a buffer. But there is no way to 'flush' that. In a sense, flushing it is exactly what the WriteFile call does, namely copying the data in the buffer to system memory space.
If you use WriteFile on a pipe, that pipe has a buffer associated with it. There is no way to flush that buffer, it is completely outside the control of the sending program, not even in its memory space. You cannot request the pipe not to have a buffer by using unbuffered I/O.
This is what MicroSoft sys about it (emphasis mine):
The WriteFile function returns when one of the following conditions occur:
* The number of bytes requested is written.
* A read operation releases buffer space on the read end of the pipe (if the write was blocked). For more information, see the Pipes section.
* An asynchronous handle is being used and the write is occurring asynchronously.
* An error occurs.
The blocking only occurs conditionally, because the pipe buffer in the OS is full, which usually will not be the case, unless you continue to dump vast amounts of data in it that no one is reading.
Pipes
If an anonymous pipe is being used and the read handle has been closed, when WriteFile attempts to write using the pipe's corresponding write handle, the function returns FALSE and GetLastError returns ERROR_BROKEN_PIPE.
If the pipe buffer is full when an application uses the WriteFile function to write to a pipe, the write operation may not finish immediately. The write operation will be completed when a read operation (using the ReadFile function) makes more system buffer space available for the pipe.
When writing to a nonblocking, byte-mode pipe handle with insufficient buffer space, WriteFile returns TRUE with *lpNumberOfBytesWritten < nNumberOfBytesToWrite.
For more information about pipes, see Pipes.
The write operation
may not finish immediately if the pipe buffer is full. I.e., normally, a write on a pipe will finish immediately, as the pipe buffer will
not be full, and this is mentioned as a necessary condition for not finishing immediately (i.e. blocking).
The problem you sketch simply does not occur in GUI->engine traffic. A GUI would never send more data than fits in the pipe buffer. It would send at most a modest amount, and then start waiting until the engine replies. And usually such a reply would only come afte the engine has read all the data it was sent.
E.g., you send a UCI engine a
position and a
go command. These are not nearly enough to fill the pipe buffer, if the game was not 1000 moves long. Now you will be waiting for a
bestmove reply. You will not recieve it before the engine will have read the newline following the
go command. Which is indeed the last thing you sent it. So at that point the pipe buffer will be empty. Only then you will start sending the engine the next
position command, which will thus go into an empty buffer, and not be able to fill it by itself. The WriteFile call will thus not block, and return instantly.
