Beej's Guide to Unix Interprocess Communication(ecst.csuchico.edu)
ecst.csuchico.edu
Beej's Guide to Unix Interprocess Communication
http://www.ecst.csuchico.edu/~beej/guide/ipc/
11 comments
A much more recent version of this is available @
http://beej.us/guide/bgipc/output/html/multipage/index.html
i used this last week! i was working out how best to coordinate access to a gpu (opencl) and decided on ipc - the shared memory messaging reduces overhead on the host, and we can have a bunch of processes running on different cores on the cpu all feeding to the gpu when appropriate. this was the best background on ipc i found.
(incidentally - does the above make sense? i am new to both gpus and ipc...)
(incidentally - does the above make sense? i am new to both gpus and ipc...)
This is pretty good. But it's important to understand just how much has changed over time, and to add appropriate grains of salt.
For instance, the signals reference is showing its age. On Mac OS X (and probably other systems), the current signal mechanism does not uninstall the handling function after a signal fires. Also, you could have an entire discussion on the proper use of signals within multithreaded applications, and there is no mention of threads in this tutorial (because it's dated 1997).
For instance, the signals reference is showing its age. On Mac OS X (and probably other systems), the current signal mechanism does not uninstall the handling function after a signal fires. Also, you could have an entire discussion on the proper use of signals within multithreaded applications, and there is no mention of threads in this tutorial (because it's dated 1997).
Also worth noting, in Mac OS X and other BSDs pipes are bidirectional. I assumed that was some Snow Leopard craziness, but it comes from System V.4 in 1988.
There must be a theological divide on the matter judging from the wording of the GNU man page which proudly proclaims pipes unidirectional.
There must be a theological divide on the matter judging from the wording of the GNU man page which proudly proclaims pipes unidirectional.
shutdown(2) lets you report EOF while still reading from a socket, so you can cleanly receive your peer's messages and EOF. Pipes only support close(2), so you can't report EOF without forcing your peer to handle SIGPIPE/EPIPE as well as ignoring anything else they want to send. And if your peer is writing and doesn't expect reads to work also (POSIX doesn't call for it), your own writes are just going to block and never be read.
On Mac OS X (and probably other systems), the current signal mechanism does not uninstall the handling function after a signal fires.
Be aware that this is often a difference in signal(2) vs sigaction(2), and even those often have slightly different implementations. Note the SA_RESETHAND flag to sigaction, and the section "Portability" in signal(2) in Linux's man pages.
Be aware that this is often a difference in signal(2) vs sigaction(2), and even those often have slightly different implementations. Note the SA_RESETHAND flag to sigaction, and the section "Portability" in signal(2) in Linux's man pages.
Some would say that if signals are the answer, the question must be wrong.
"How do you uniformly and asynchronously request that a process clean up its resources and exit, when e.g. the hardware is about to shut off?" That doesn't sound like a bad question to me.
the only time i've made good use of signals is for exiting. you can catch ctrl-c that way, so your app isn't forced to exit without being able to clean up. and you can install a SIGQUIT handler to take action when the os wants you to shut down.
I'm up-voting in homage to nostalgia. I still remember being giddy the first time I read Beej's network programming. Oh, innocence.
I'll agree with the nostalgia, bringing me back to college. I was at Chico with him. I however don't miss HPUX, I do miss my Slackware though.
Wow seeing "Beej's" made me feel nostalgic.
Out of date lecture notes with what looks like a bias for HP-UX. There are better sources of information.
can you provide the links to the better sources? otherwise this isnt a very useful comment.
Sorry, I was trying to be concise. I'll aim to be useful. I think the guide as it is, is not only old but incomplete and mostly points to man pages. It's saving grace is the examples, which could easily be taken from a code search.
The Stevens Unix network programming is a better source if you have it. Vendor documentation is often better too. Say you were interested in SYSV IPC:
http://www.ibiblio.org/pub/Linux/docs/LDP/programmers-guide/... http://www.advancedlinuxprogramming.com/alp-folder/alp-ch05-... http://developers.sun.com/solaris/articles/named_pipes.html http://www.ibm.com/developerworks/aix/library/au-ipc/
Working code like the APR is worth reading for portability issues, particularly with sockets. I'm sure there are many other examples.
Given all this would you really use this guide when writing code?
The Stevens Unix network programming is a better source if you have it. Vendor documentation is often better too. Say you were interested in SYSV IPC:
http://www.ibiblio.org/pub/Linux/docs/LDP/programmers-guide/... http://www.advancedlinuxprogramming.com/alp-folder/alp-ch05-... http://developers.sun.com/solaris/articles/named_pipes.html http://www.ibm.com/developerworks/aix/library/au-ipc/
Working code like the APR is worth reading for portability issues, particularly with sockets. I'm sure there are many other examples.
Given all this would you really use this guide when writing code?
SysV IPC has message queues? I didn't know that, that looks useful.
I remember printing that. Thanks for the blast from the past! :)
That's where I have learned what a socket was many years ago :)
Wish if Beej's guides were continued. They are 'cool'.
I remember my first UDP packet...