When you operate on named pipes,
you have a choice of opening them in PIPE_
mode or PIPE_
mode.
When you read from
a PIPE_
pipe,
the read blocks until data becomes available
in the pipe.
When you read from a PIPE_
pipe, then the read
completes immediately even if there is no data in the pipe.
But how is this different from a PIPE_
pipe
opened in asynchronous mode by passing
FILE_
?
The difference is in when the I/O is deemed to have completed.
When you issue an overlapped read against a PIPE_
pipe,
the call to ReadFile
returns immediately, but the
completion actions do not occur until
there is data available in the pipe.
(Completion actions are things like
setting the event, running the completion routine,
or queueing a completion to an I/O completion port.)
On the other hand, when you issue a read against a
PIPE_
pipe,
the call to ReadFile
returns immediately
with completion—if the pipe is empty,
the read completes with a read of zero bytes and the error
ERROR_
.
Here's a timeline, for people who prefer tables.
Event | Asynchronous PIPE_WAIT |
PIPE_NOWAIT |
---|---|---|
pipe initially empty | ||
ReadFile | Returns immediately with ERROR_ |
Returns immediately with ERROR_ I/O completes with 0 bytes |
time passes | ||
Data available | I/O completes with n > 0 bytes |
If you use the PIPE_
flag, then the only
way to know whether there is data is to poll for it.
There is no way to be notified when data becomes available.
As the documentation notes, PIPE_
remains
solely for compatibility with LAN Manager 2.0.
Since the only way to use pipes created as PIPE_
is to poll them, this is obviously not a recommended model for
a multitasking operating system.