Beejs Guide to Unix IPC | Hacker News Reader

Beejs Guide to Unix IPC

beej.us

77 pointsfixmenow19 comments

I learned socket programming in 1999 w/ this guy's site. Glad to see it's still around.

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!

Beej is a poor man's Richard Stevens. Amazing technical writing, for free.

He's also a great game programmer--and a photographer.

Worked with him at Z-Axis (Activision) years ago.

I'll take programmer, but photographer is far too kind. :)

Hey, I liked your photos. I remember the ones you shot in the cave, with all the slave flashes.

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.

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!?

Yes, you are the only one. Get a textbook instead.

3.6 What's With These Ooompty Goofty Section Titles?

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.

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).

He also maintains the Pirate Image Archive http://beej.us/pirates/index.html

Previously: http://news.ycombinator.com/item?id=584557

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."

Thanks for writing them!

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.

Even more so because he doesn't mention the major danger zone of signals -- your code needs to be async-safe:

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.

Ok, folks--this is excellent feedback. So...

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.)

You're awesome (and the update looks great).

Damn--it's been so long since I looked at it, I'd forgotten I hadn't updated it.

Yes, the old signals are crap. I REALLY have to update that section (which, in my defense, was written about 15 years ago.)

Reply on news.ycombinator.com