3 ms·
> Two communicating processes on a single machine have a few options Curiously, the article does not even mention pipes, which I would assume to be the most ob
by spacechild1 3y ago
> Two communicating processes on a single machine have a few options
Curiously, the article does not even mention pipes, which I would assume to be the most obvious solution for this task (but not necessarily the best, of course!)
In particular, I am wondering how Unix domain sockets compare to (a pair of) pipes. At first glance, they appear to be very similar. What are the trade-offs?
- tptacek 3y agoThe pipe vs. socket perf debate is a very old one. Sockets are more flexible and tunable, which may net you better performance (for instance, by tweaking buffer sizes), but my guess is that the high order bit of how a UDS and a pipe perform are the same. Using pipes instead of a UDS: * Requires managing an extra set of file descriptors to get bidirectionality * Requires processes to be related * Surrenders socket features like file descriptor passing * Is more fiddly than the socket code, which can often be interchangeable with TCP sockets (see, for instant, the Go standard library) If you're sticking with Linux, I can't personally see a reason ever to prefer pipes. A UDS is probably the best default answer for generic IPC on Linux.
- deleted 3y ago[deleted]
- xuhu 3y agoWith pipes, the sender has to add a SIGPIPE handler which is not trivial to do if it's a library doing the send/recv. With sockets it can use send(fd, buf, MSG_NOSIGNAL) instead.