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!
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.)
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!?
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."
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).
19 comments
[ 4.0 ms ] story [ 48.6 ms ] threadEdit: 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!
Worked with him at Z-Axis (Activision) years ago.
Didn't I give you my IR-pass filter gel sheets? Did you ever end up doing anything with them?
Sent you an email; we should catch up.
https://www.securecoding.cert.org/confluence/display/seccode...
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.)
Yes, the old signals are crap. I REALLY have to update that section (which, in my defense, was written about 15 years ago.)
How do you use fork? "Oh, just look under the title "I'm mentally prepared! Give me The Button!"" --- what the heck!?
Luckily for you, there are piles of books and web docs that are totally written in your style. :) I take no offense--it's not for everyone.
And it was actually written over a decade ago, so there is that... but I'll probably keep writing the same way anyhow.
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.
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."
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).