[nh2]

The UNIX pipe has the (for many systems) undesirable negative property of losing data in the pipe when the receiving process terminates: Anything in the kernel buffer of the pipe gets lost.

Since the pipe is generally unidirectional, the sending process has no way of knowing whether the receiving process has received, or even more successfully processed, anything sent. For that, one needs to make a pipe in the opposite direction and that is not as easy anymore; it also requires building your own protocol to identify and acknowledge sent work items.

[10000truths]

> The UNIX pipe has the (for many systems) undesirable negative property of losing data in the pipe when the receiving process terminates: Anything in the kernel buffer of the pipe gets lost.

There are solutions for that, though:

* You can observe and/or persist intermediate data with `tee`

* You can use a named pipe, whose lifetime is bound to an inode instead of the processes

* You can dup the read end of the pipe and pass the extra file descriptor to a crash handler process

None of these are esoteric. You do need a basic understanding of Unix primitives, but any half-decent computer science course will cover them.

[zbentley]

> the pipe is generally unidirectional

So are most message queues.

If the producer needs to know when the consumer has finished work, that's not a queue; that's an RPC.

[groundzeros2015]

And to have a hope of solving that problem you need to restore producer and consumer thread states without encountering that problem.