What are the main disadvantages of Windows pipes for inter-process communication?

Question

Say you are splitting a monolithic Windows program into reusable components which could communicate with each other using some sort of inter-process communication (IPC), and, fo

Answer 1

You can create two-way anonymous pipes using CreatePipe() Win32 API call, so piping input/output is not the only way. You simply get a new file handle you can give to the other process.

Anonymous pipes are based on shared memory, but do not support asynchronous operations (through ReadFileEx, ReadFileWrite). Performance issues (disadvantages) are thus 1) synchronous operation, 2) memory copying, 3) interprocess synchronization. Generally, "raw" shared memory (memory mapped file without an actual backing file) and named pipes will be faster, and sockets and Window messages will be slower (than anonymous pipes).

You cannot use I/O Completion Ports (IOCP) with anonymous pipes, instead you'll have to "poll" the pipe, incurring extra context switches. In addition to serializing the data, the serialized data has to be copied around in memory, as you cannot write directly to the shared memory. One process also has to wait for another, implying that the other process has to signal an interprocess synchronization primitive. Performance depends heavily on the size of the messages (ratio of read/write calls to amount of data sent), because for each read/write the process has to make context switches and possibly spin/sleep.

All methods except "raw" shared memory require memory copying and some sort of interprocess signaling (synchronization), so the main disadvantage of anonymous pipes is synchronous operation. You'll hit the ceiling when transmitting large number of messages, when the CPU spends most of its time doing context switches.

Performance-wise, named pipes are better because you can have worker thread(s) processing async notifications using IOCP, and can even receive multiple messages with one call, thus reducing the API overhead. If making your own components, the extra trouble from giving a name to the pipe is well worth the trouble (and you can even connect across networks). Later Windows versions implement special routing for local sockets, which also do support IOCP.

The fastest method would be to use shared memory directly, but then you will have to take care of interprocess synchronization yourself. It's possible to implement lock-free pipes yourself, but in case you're not constantly transmitting data, you'll still have to use synchronization primitives to notify/wake the listening process up.

Also note that using files does not imply that you would be limited by disk speed, as you can use memory mapped files and even with normal files, the cache manager handles the reading/writing. The other methods (RPC, clipboard, etc) are based on these "standard" methods, which means they'll just add some extra layer of protocol and are meant to be easier/more helpful, or more suitable for some programming environment (but not to be faster).