The IPC is in SystemV flavor but I think these days we normally should adopt Posix IPC instead especially for Linux/BSD, am I missing something?<p><pre><code> "On Linux and FreeBSD there is big advantage of posix queues, as handler given by mq_open are basically file descriptor which can be polled/epolled/selected/kqueued"
"all POSIX IPC is thread-safe, while most SysV IPC is NOT"</code></pre>
Past related threads:<p><i>Beej's Guide to Unix IPC (2010)</i> - <a href="https://news.ycombinator.com/item?id=9619375" rel="nofollow">https://news.ycombinator.com/item?id=9619375</a> - May 2015 (31 comments)<p><i>Beejs Guide to Unix IPC</i> - <a href="https://news.ycombinator.com/item?id=1525227" rel="nofollow">https://news.ycombinator.com/item?id=1525227</a> - July 2010 (19 comments)
fork() is rarely ideal, unless followed by exec() to launch another processes. That copy-on-write thing often wastes too much physical memory. I think threads are usually better, the shared memory allows to marshal large volumes of data without making copies.<p>I like poll() much better than signals. Signals are too limiting, and too arcane. It's much easier to use poll() and dispatch things manually based on the signaled handles, at least there's a guarantee your code won't be interrupted by another event.<p>Pretty much all modern kernel things are compatible with poll. There's eventfd() which acts as an event or semaphore, message queues (but not the ones from the article, better ones, created with mq_open not msgget), Unix domain sockets for cross-process messaging. There's more, poll() can track termination of processes (see pidfd_open), page flip events in a GPU with DRM, consumed or available video/audio samples with V4L2 or ALSA.
I personally dislike Beej's writing style. I tried to like his Network Programming guide but I found that most of what it conveys can be learned more quickly by simply reading the relevant POSIX/Linux manpages.
Beej's guides are amazing with a memorable and entertaining writing style. I remember reading his network guide almost two decades ago when I was a kid, had just heard of this thing called a socket, but the only connotation I had for one at the time was a wall socket. His guide helped me understand networking but more importantly it made it a fun experience for a programmer just starting out.
I freaking love his guides, I'm currently reading through his C guide: <a href="https://beej.us/guide/bgc/" rel="nofollow">https://beej.us/guide/bgc/</a><p>It's very entertaining to read though which holds my attention well, and is well suited to people with existing programming experience. I've tried to read K&R but I keep coming back to Beej's.