Now we consider the following questions: how can the parent process communicate with its child? Or how can children processes communicate with other children? The exact answer depends on the exact problem being treated, but in general we call the several different approaches to this question by the name of Interprocess Communication (IPC).

On possibility for IPC is to use sockets. This approach is based on explicit message passing, and has the advantage that processes can be distributed anywhere on the Internet, among several different machines. An application designed to use sockets can fairly easily be re-deployed as a multi-server application when its needs outgrow a single server.

Another possibility is the use of mmap, which is a hack, although a very common one. Mmap uses memory sharing as an indirect way of communicating. The way that this works is that all processes map the same ?le into a ?xed memory location. In this case, however, since we have objects being read fromandwritten to a sharedmemory region,wemust use some kind of process-level synchronization. Unfortunately, these synchronization procedures are in general much more expensive than the use of threads itself.

One can also use signals; in this case, processes can send and receive integer numbers associated with particular signal numbers. In order to be able to receive and treat these numbers, processes must ?rst set up signal handlers. This approach works best for rare events1. In general, signals are not very useful for parallel or concurrent programming.

The other possibility is the use of pipes. These are unidirectional communication channels which make it possible for the output of one program to be used as input to another one, just like in Unix (for example, when we use the pipe symbol, as in "ls j wc -l". The advantage of using pipes is that they are easy and fast.