What’s the difference between an asynchronous PIPE_WAIT pipe and a PIPE_NOWAIT pipe?

When you operate on named pipes, you have a choice of opening them in PIPE_WAIT mode or PIPE_NOWAIT mode. When you read from a PIPE_WAIT pipe, the read blocks until data becomes available in the pipe. When you read from a PIPE_NOWAIT pipe, then the read completes immediately even if there is no data in the pipe. But how is this different from a PIPE_WAIT pipe opened in asynchronous mode by passing FILE_FLAG_OVERLAPPED?

The difference is in when the I/O is deemed to have completed.

When you issue an overlapped read against a PIPE_WAIT pipe, the call to Read­File 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_NOWAIT pipe, the call to Read­File returns immediately with completion—if the pipe is empty, the read completes with a read of zero bytes and the error ERROR_NO_DATA.

Here's a timeline, for people who prefer tables.

Event Asynchronous PIPE_WAIT PIPE_NOWAIT
pipe initially empty
ReadFile Returns immediately with ERROR_IO_PENDING Returns immediately with ERROR_NO_DATA
I/O completes with 0 bytes
time passes
Data available I/O completes with n > 0 bytes

If you use the PIPE_NOWAIT 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_NOWAIT remains solely for compatibility with LAN Manager 2.0. Since the only way to use pipes created as PIPE_NOWAIT is to poll them, this is obviously not a recommended model for a multitasking operating system.

Comments (14)
  1. Adrian says:

    Very useful comparison.  Thanks.

  2. dave says:

    Or, PIPE_WAIT with overlapped is the RSX model, PIPE_NOWAIT is the Unix model :-)

  3. Alex Grigoriev says:

    Does pipe IO use IRPs and FILE_OBJECT? There is a big problem with a handle opened for synchronous IO. You can't close the handle (it will hang) until a pending read operation completes. If there is no data, you're hosed.

  4. Joshua says:

    @dave: select() is the Unix model. On Unix, select() works on everything.

  5. @Alex I believe you can call CancelIo(handle) if you want to abort the read.

  6. Gabe says:

    Joshua: In the Unix model, select() only works on files (or things you can call creat() on). You can't use select() to tell you when a process has exited or a semaphore is unlocked.

  7. Tihiy says:

    Is there any Windows API layer or technology which can be used instead of NT named pipes without much pain? I.e. some alternate IPC mechanism with same principles.

  8. dave says:

    Re: Tihiy

    Why?  If you want reliable two-way byte or message exchange, why look for something other than the thing that is designed for reliable two-way byte or message exchange?

  9. Iain Clarke says:


    I echo "dave"'s response – if you want something like named pipes, then use named pipes!

    The nearest alternative I can think of would be MSMQ.


  10. Martin says:

    @ Alex Grigoriev and @Maurits

    CancelIo is probably not what you want – it only works if called from the (presumably blocked) thread that issued the read. I guess it is only intended for use with overlapped IO.

    The MSDN documentation is very clear and specific about this:


    Cancels all pending input and output (I/O) operations that are issued by the calling thread for the specified file. The function does not cancel I/O operations that other threads issue for a file handle.

    To cancel I/O operations from another thread, use the CancelIoEx function."

    So you probably want CancelIoEx.



  11. Worf says:

    Tihiy: there's always TCP sockets if you want reliable byte transport, works great even through localhost…

  12. Drizzt says:

    @Raymond: but…is there really someone asking for thing like this?

    I mean, it's so damn obvious, it took me 5 minutes and 2 readings of the post to understand what was it all about (nothing at all, in the end). Is the level of computer programmers so low?

    [A lot of my articles are "restating the obvious"-type content inspired by somebody (in this case, a customer) who asked about it. I used to title them "restating the obvious" but I've gotten lazy and don't bother much any more. -Raymond]
  13. kinokijuf says:

    <sarcasm>You used to title them „restating the obvious”, but that would be just restating the obvious, right?</sarcasm>

  14. Alex Grigoriev says:


    No, I'm not talking about CancelIo. I'm talking about CloseHandle.

Comments are closed.

Skip to main content