Beej's Guide to Unix IPC (2015)
beej.us
beej.us
"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"The more elaborate portions of System V IPC trace their origins to "Columbus UNIX" that was developed so a database could run on the platform.
Thanks for the great guides. :)
Why? Because inevitably the code is going to be either wrapped, too tiny or overflowing. Furthermore, syntax highlighting is a complete utter mess in ebooks.
Reviews don’t lie. People don’t like it. And it’s obvious where ebooks shine and where they don’t.
Personally: I want proper typesetting and constancy in the layout. But with eReaders, ebooks work pretty well and PDFs don’t. With iPads, PDFs are better IMO. But for technical books PDFs set by a professional typesetter like Springer is fantastic. Great typography and layout.
I hope this idea catches on. ePub/Mobi files are no good IMO.
So if the code you're writing is amenable to those constraints, it would probably work quite well, but AbstractWidgetLocalizerManagerFactoryBeans are right out.
It's on my list of things to mess with after I get to version 1 of the C guide. :)
Beej, so nice to see you on this site, such a fan of your work. Used your guide a decade ago to implement socket select() on a system-critical app. Mad props for doing some awesome work!
I'm reasonably pleased with the Dercuano formatting, though some people hate it; it doesn't work very well on a laptop screen, but on a cellphone screen I think it's close to optimal, except where it's just broken. It's probably passable on a small ereader but would be painful on a large one, except maybe in landscape facing-pages mode. (I hacked together the HTML renderer to generate the PDF in a few days, and I didn't implement, for example, table layout; and when it has to fall back to a glyph that isn't in lmtlc, it screws up the column widths.)
I think I've said this before, but I really appreciate Beej's Socket Guide! Thank you for writing it!
Beej's Guide to Unix IPC (2010) - https://news.ycombinator.com/item?id=9619375 - May 2015 (31 comments)
Beejs Guide to Unix IPC - https://news.ycombinator.com/item?id=1525227 - July 2010 (19 comments)
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.
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.
Signals are interrupts, which are faster than an event loop but very bug-prone, especially in C (few C library functions are safe in interrupts), but shared-memory threads are too, for almost exactly the same reasons. If you want to share memory between processes, it's easy enough to use mmap().
Both threads and signals are somewhat tamer in Python, but lose some of their advantages on the way.
Interrupts are really needed for three reasons: device driver latency and buffering (multithreaded CPUs probably being a superior alternative), killing infinite loops, and userspace virtual memory. Unix signals are useless for the first and arguably so bad at the other two that Unix would have been better off without them.
Generally running multiple processes of the same program with different exec() calls uses more memory than forking it at startup, not less. It's true that threads use less still, and event loops less than that, when you don't have a multicore scaling problem.
If you're looking at writing your own event loop, select() is more convenient than poll(), and io_uring is worth checking out. kqueue, iocp, and epoll are faster than poll(). Also though maybe just try libev, libevent, or libuv instead of writing your own.
It's only easy when all of the following is true: (1) sharing one time only (2) Sharing exactly one continuous buffer, as opposed to anything more complicated with pointers inside (3) Sharing between processes one-to-one. When any of these things is false, mmap becomes hard. For instance, despite C++ std::vector is a continuous buffer, when sharing a mutable one that grow/reallocate thing gonna cause issues.
> select() is more convenient than poll()
Strongly disagree. These macros and the bitmap is pure BS. For some handle types like sockets, for hardware reasons (multicore CPUs) Linux no longer guarantees sequential file descriptors. Even the manual page says "WARNING: select() can monitor only file descriptors numbers that are less than FD_SETSIZE (1024) - an unreasonably low limit for many modern applications - and this limitation will not change. All modern applications should instead use poll(2) or epoll(7)"
poll() is awesome in comparison, the API with that array of simple structures is perfect for the job. At least in terms of usability, AFAIK epoll does better performance-wise.
> io_uring is worth checking out
Right, but the use case is different, it's only for I/O.
> kqueue, iocp
Not available on Linux?
> epoll
Yeah, but I think to truly benefit from this one, need multithreading. Multithreaded async I/O is hard, I think people only doing that when they absolutely have to for performance reasons.
> just try libev, libevent, or libuv instead of writing your own
My use cases are probably different. I rarely using poll() for network sockets, it's usually other things: process and threads synchronization, timers with timerfd(), hardware devices (GPU, sound card, hardware video codecs).
huh? this would be a severe POSIX violation, which says that for socket and accept, "The file descriptor shall be allocated as described in File Descriptor Allocation.": "All functions that open one or more file descriptors shall, unless specified otherwise, atomically allocate the lowest numbered available (that is, not already open in the calling process) file descriptor at the time of each allocation."
I'm not sure what you mean by "sharing one time only" or "sharing between processes one-to-one"; can you elaborate?
It isn't really true that select() can only monitor file descriptor numbers less than FD_SETSIZE; you just have to allocate the bitmaps differently instead of using the fd_set type. Libevent does this, for example.
io_uring isn't really only for I/O; you can use it for madvise(), poll(), and timers as well. Normally I'd be comfortable with saying that's "I/O" but in this context poll() and timers are the things you're implicitly opposing to "I/O".
Yes, kqueue and iocp are not available on Linux. But io_uring and epoll aren't available on other operating systems, so I thought it was worthwhile mentioning the corresponding facilities there.
Why do you say you need multithreading to truly benefit from epoll? If you have an I/O-bound process that has a lot of file descriptors open, running in an event loop, epoll is a faster alternative to select() (or, as you say, poll()), isn't it?
This thing about nonsequential socket file descriptors is news to me; I hadn't heard anything about it, though I admit I haven't been paying attention. Where can I find out more?
By one time only, I meant that you only want to pass the data once, as opposed to sharing the data and being able to update it on one side and see updates on the other one.
It’s not impossible, but practically hard to implement growable/shrinkable shared memory areas, the communicating processes need to unmap and remap the virtual memory regions.
It’s similar with more than 2 processes sharing the memory. Technically doable but hard in practice, for instance it’s easy to leak these memfd handles.
None of these issues are present for threads sharing the address space.
> you just have to allocate the bitmaps differently instead of using the fd_set type
When really unlucky, with these bitmaps one gonna need to waste kilobytes of memory to represent a set with only a couple of handles. The RAM itself is usually cheap at that scale, the problem is the performance overhead of searching for the set bits.
> epoll is a faster alternative to select() (or, as you say, poll()), isn't it?
Right, but for IO bound things, epoll() + multithreading is even faster. Modern network cards are aware of multi-core CPUs on the other side of the PCIe bus. Faster cards like 10 Gbit/second have multiple transmit/receive queues designed to interact with different CPU cores.
OTOH, when things aren’t that I/O bound, the single dispatcher thread is adequate, and the API overhead of poll() is reasonable too, given the usability win.
> Where can I find out more?
Yeah, you’re right about that, accept() never does that, according to specs. However, note the F_DUPFD parameter of fcntl: duplicate the file descriptor using the lowest-numbered available file descriptor greater than or equal to arg. This alone means that for libraries or long-lived projects, relying on file handles to be small numbers is fundamentally unreliable.
Probably you shouldn't use select() or poll() in a library unless it's something like libevent. Libraries that want to own the event loop are impossible to use together unless you're willing to resort to multithreading.
Yes, it's true that you can use F_DUPFD (or dup2()) to request a high-numbered file descriptor. As I see it, that's not really a matter of luck. The only reason I can think of to do that is for some sort of art project or side-channel communication where your file descriptor numbers spell out a message or something.
The biggest problem with select() is that it will corrupt your stack if you use it with an fd with a value >= 1024. Since you can't easily control fd values, you must assume that calling select() is UB unless explicitly proven otherwise. There are also performance problems due to having to set up the sets before each call, but these are minor in comparison.
Or you could just not have thousands of open files in a single process, which is the way every single Unix program worked for the first 25 years of Unix. I have 269 processes running on this machine right now and none of them is using a file descriptor greater than 255. Even Firefox is only using up to fd 75. The worst offender is gnome-terminal, using fds up to 226, and its children. Having thousands of simultaneously open files is a useful way to structure a few specialized programs like chat servers and load balancers, but it's not something most programs need to worry about.
Of course in a library the situation is different, but you probably shouldn't be calling poll() or select() in a library unless it's something like libevent, libev, or libuv, because you can't use two such libraries in the same program unless you're willing to suffer multithreading.
... Which of course seems very silly today. Signalfd is a much nicer API to use for new programs!
Things like signals, file locking and mmap are still pretty important. Even if your using dbus. (Eg use dbus to share a file and mmap it)
I think dbus works great for service discovery and for low-frequency low-bandwidth communication. For other cases, people just exchange a file descriptor over dbus and proceed to talk directly to each other.
I don't know network programming very well, but what little I know was learned from Beej.
It's actually been quite rare in my professional programming career that I've had to use any of these things that I learned from Beej but... when I needed them.... I knew where to look and, knowing even just that, it's made me look like a wizard. Honestly, I can't see a 'donate' link here, but I really feel that I should.
I really do need to update it since significant advances have been made since it was written nearly 25 (!!) years ago.
> Before we go on, why would I even begin to bother pointing out that a pound sign is called an octothorpe? The answer is simple: I think the word octothorpe is so excellently funny, I have to gratuitously spread its name around whenever I get the opportunity. Octothorpe. Octothorpe, octothorpe, octothorpe.
I can't find it right now but somewhere in the guide in a different chapter, he randomly inserts "Octothorpe"... good comedy. I think this kind of writing is exceedingly rare and immensely enjoyable.
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.
For example, he doesn't seem to understand the difference between arrays and pointers -- at [1] he says:
You can’t [get the length of an array] ish. C doesn’t record this information [footnote 50]. You have to manage it separately in another variable.
[footnote 50] says "Since arrays are just pointers to the first element of the array under the hood, there’s no additional information recording the length"
And then later he says:
There is a trick to get the number of elements in an array in the scope in which an array is declared. But, generally speaking, this won’t work the way you want if you pass the array to a function [footnote 51]
[footnote 51] says "Because when you pass an array to a function, you’re actually just passing a pointer to the first element of that array, not the “entire” array."
Footnote 51 is correct, and contradicts footnote 50.
There is a simple, and correct, way to explain this:
Arrays and pointers are distinct types in C but arrays are converted to a pointer to their first element, except when it is the operand of the sizeof operator, the _Alignof operator, or the unary & operator, or is a string literal used to initialize an array.
Yes, it's more wordy, but it's what's actually going on. Arrays aren't pointers, but he insists on claiming they are throughout. Footnote 51 shouldn't be a footnote, it should be prominent in the text.
[1] https://beej.us/guide/bgc/html/split/arrays.html#fnref50
P.S. Not going to go into it here, but his "unix" network programming guides used to be full of linux-specific things (without pointing this out), but I think it's improved over the last 10 or so years.