There is a inter-process communication use case were two related processes need to communicate requests/responses (fixed structure messages) to each other, no prioritization for requests is needed.
According to my understanding since this is a message-based communication it is more convenient to use message queues. But I encountered some implementations that uses pipes (they construct message headers to be able to pack/unpack messages over byte stream).
So my question is, what is the benefit of using pipes over message queues in this use case (or in message-based communication in general), is this just a bad design or there are benefits that overcome the cost of adding code to pack/unpack messages over byte stream?
Let’s try to make a short table.
less resources, simple
always available just everywhere
needs CONFIG_POSIX_MQUEUE Linux Kernel option
easy to use, known and used everywhere
almost forgotten nowadays and specific use cases
messages less than PIPE_BUF (4096 on linux, at least 512) are guaranteed be written/read in one go
builtin messages boundaries
just a fifo
builtin priorities of messages, the most important get’s delivered first
you can use poll/select
You can’t use poll/select. (Except you can on Linux, not portable).
auto-cleanup after unlink() / needs synchronization of processes to do proper cleanup
standard way of sharing a channel between forks / is local to the process
can communicate between unrelated processes / the name is global, unix permissions access appplies
ulimit -n (/etc/security/limits.conf) limit open file descriptors
NAME_MAX limits the name (and mqd_t is also file descriptor on linux)