1
1. Intro
You know what's easy? fork() is easy. You can fork off new processes all day and have
them deal with individual chunks of a problem in parallel. Of course, its easiest if the processes
don't have to communicate with one another while they're running and can just sit there doing
their own thing.
However, when you start fork()'ing processes, you immediately start to think of the
neat multi-user things you could do if the processes could talk to each other easily. So you try
making a global array and then fork()'ing to see if it is shared. (That is, see if both the child
and parent process use the same array.) Soon, of course, you find that the child process has its
own copy of the array and the parent is oblivious to whatever changes the child makes to it.
How do you get these guys to talk to one another, share data structures, and be generally
amicable? This document discusses several methods of Interprocess Communication (IPC) that
can accomplish this, some of which are better suited to certain tasks than others.
1.1. Audience
If you know C or C++ and are pretty good using a Unix environment (or other POSIXey
environment that supports these system calls) these documents are for you. If you aren't that
good, well, don't sweat it—you'll be able to figure it out. I make the assumption, however, that
you have a fair smattering of C programming experience.
As with Beej's Guide to Network Programming Using Internet Sockets
1
, these documents
are meant to springboard the aforementioned user into the realm of IPC by delivering a concise
overview of various IPC techniques. This is not the definitive set of documents that cover this
subject, by any means. Like I said, it is designed to simply give you a foothold in this, the
exciting world of IPC.
1.2. Platform and Compiler
The examples in this document were compiled under Linux using gcc. They should
compile anywhere a good Unix compiler is available.
1.3. Official Homepage
This official location of this document is http://beej.us/guide/bgipc/.
1.4. Email Policy
I'm generally available to help out with email questions so feel free to write in, but I can't
guarantee a response. I lead a pretty busy life and there are times when I just can't answer a
question you have. When that's the case, I usually just delete the message. It's nothing personal;
I just won't ever have the time to give the detailed answer you require.
As a rule, the more complex the question, the less likely I am to respond. If you can narrow
down your question before mailing it and be sure to include any pertinent information (like
platform, compiler, error messages you're getting, and anything else you think might help
me troubleshoot), you're much more likely to get a response. For more pointers, read ESR's
document, How To Ask Questions The Smart Way
2
.
If you don't get a response, hack on it some more, try to find the answer, and if it's still
elusive, then write me again with the information you've found and hopefully it will be enough
for me to help out.
1. http://beej.us/guide/bgnet/
2. http://www.catb.org/~esr/faqs/smart-questions.html
