

Beejs Guide to Unix IPC - fixmenow
http://beej.us/guide/bgipc/output/html/multipage/index.html

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

~~~
hoggle
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!

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

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

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

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

~~~
SomeCallMeTim
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.

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

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

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

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

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

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

~~~
silentbicycle
Thanks for writing them!

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

~~~
ant5
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...](https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+only+asynchronous-
safe+functions+within+signal+handlers)

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.

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

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

