It's a great resource and was also the place I started learning network programming. Of course Stevens writings are a must too but beej's guide is an enthusiastic, practical and fun to read primer into the topic. I loved it - credit where credit's due!
Edit: the credit remark is not connected with any comments here - it's a general statement from somebody who enjoyed learning from that resource - essentially wanting to say - thank you beej!
Am I the only one who doesn't like the "funny sounding" titles and subtitles in technical writing? I know it got fashionable decades ago in computer magazines but it's really annoying, at least for me, in any text that is not a really short article, since the titles in longer texts should be used for a reference and not "to make the popular article appear less boring."
How do you use fork? "Oh, just look under the title "I'm mentally prepared! Give me The Button!"" --- what the heck!?
I'm little bit disappointed by fact that almost every text on Unix IPC (including this one) gives too much emphasis to System V IPC primitives, with their one global 32-bit namespace for everything and other brain damage.
Anything that you can do with SysV IPC can be done better using sockets or mmap-based shared memory (or POSIX semaphores, which are by the way implemented by mmaping one page of shared memory, at least on Linux).
While a few of the details have shifted over time, it's still a good overview, IMHO.
The Richard Stevens books (_Advanced Programming in the Unix Environment_, 2nd ed. ('APUE'), _Unix Network Programming_ vols. 1 & 2) get much deeper into the details, when you need them, but Beej's guides will definitely give you a running start.
This is absolutely right--in fact the purpose of the 'Guides are to show one or two paths up that initial hill that can appear so daunting from a distance.
I recommend Stevens's books every chance I get. They are excellent. I doubt I could do a better job than he did for that particular target audience. My stuff, I try to wedge in between "utter beginner" and "Stevens". And that's fine for me, since I get stoked over the initial rush of "holy crap--look what this can do!" while Stevens is more "ok, now that you're on board, let's get some serious learning going."
All good and fine but I think, you are better off learning signals from some other resource as well. It's alright to get started but you would want to learn the modern way of doing signals with sigaction(POSIX). IIRC, even the corresponding chapter in this guide mentions this in passing.
Signal handlers will be called in the middle of execution of another function. There's no way to tell what locks may be held or what resources may be allocated/reserved; you can only safely call functions that have been evaluated to be and declared async-safe.
That doesn't give you many options within a signal handler, but it also gives you a very good reason not to use them at all, if you can avoid them.
On the BSDs and Mac OS X you can use kevent to handle signals via EVFILT_SIGNAL, which means you can avoid this mess altogether. On Linux, you have signalfd() which will let you monitor a file descriptor combined with select()/epoll()/etc to handle signals.
I've updated the page, and it was at the end of a long day, so I've probably introduced a raft of new errors and omissions. Now it's all sigaction() all the time, and there is hardly a mention of signal(). I included the async stuff and added sig_atomic_t info.
The complexity of sigaction() et al is pretty high compared to signal(), so I only gave it a glancing blow. I do agree with many posters that there is probably a better way than signals to do whatever it is you're doing. I don't think I've ever used them in real life other than to reap dead children or handle SIGINT. (Of course, people do--it just might not be that common.)
