Inter-process Communication

- Processes often need to communicate with each other in order to
  accomplish useful tasks. The OS provides several mechanisms to
  enable processes to communicate with each other.

- Shared memory is the simplest way in which two processes can
  communicate with each other. By default, two separate processes have
  two separate memory images, and do not share any memory. (Note: a
  forked child has the same memory image as the parent at creation,
  but any changes made to the child's memory will not be reflected in
  the parent.) Processes wishing to share memory can request the
  kernel for a shared memory segment. Once they get access to the
  shared memory segment, it can be used as regular memory, with the
  property that changes made by one process will be visible to the
  other and vice versa.

- A significant issue with using shared memory is the problem of
  synchronization and race conditions. For example, if several
  processes share a memory segment, it is possible for two processes
  to make a concurrent update, resulting in a wrong value. Therefore,
  appropriate synchronization mechanisms like locking should be used
  when using shared memory.

- Signals are another light-weight way for processes and kernel to
  communicate with each other, and are mainly used to notify processes
  of events. For example, when a user hits Ctrl+C, the OS sends a a
  signal called SIGINT to the running process (as part of handling the
  interrupt generated by the keyboard). When a process receives a
  signal, the normal execution of the process is halted, and a
  separate piece of code called the signal handler is executed by the
  process. A process template comes with default signal handlers for
  all signals, so that every program will not need to have code to
  handle signals. For example, for the Ctrl+C signal, the process will
  terminate by default. However, a program can have its own in-built
  signal handling function, that can be passed to the kernel with the
  "signal" system call. The OS will then invoke this new function when
  the process receives a signal. Signals are not just for
  communication between the OS and processes. One process can use
  signals to communicate with another process also. The "kill" system
  call can be used by a process to send a signal to another process
  whose pid is specified as an argument to the system call.

- Sockets are a mechanism to communicate between two processes on the
  same machine, and even between processes on different
  machines. Network sockets are a standard way for two application
  layer processes running on different machines (e.g., a web client
  and a web server) to exchange data with each other. Similarly, two
  processes on the same machine can use Unix domain sockets to send
  and receive messages between each other. The usage of Unix domain
  sockets is very similar to the usage of network sockets. That said,
  sockets are more widely used for communicating across hosts than
  across processes on the same host.

- Sockets present an interesting case study on blocking
  vs. non-blocking system calls. Some socket system calls (e.g.,
  accept, read) are blocking. For example, when a process reads from a
  socket, the system call blocks until data appears on the socket. As
  a result, while the process is blocked, it cannot handle data coming
  on any other socket.  This limits the number of concurrent
  communications a process can sustain. There are several techniques
  to fix this problem. A process could fork off a new child process
  for every connection it has, so that a child process can be
  dedicated to reading and writing on one connection
  only. Alternately, a socket can be set to be non-blocking, and the
  process can periodically poll the socket to see if data has
  arrived. Finally, system calls such as "select" can be used to get
  notifications from the kernel on when a socket is ready for a read.

- Pipes: a pipe is a half-duplex connection between two file
  descriptors --- data written into one file descriptor can be read
  out through the other. A pair of file descriptors can be bound this
  way using the "pipe" system call. The two ends of the pipe are
  referred to as a read end and a write end. Reading from and writing
  to a pipe can be blocking or non-blocking, depending on how the pipe
  is configured. The data written to a pipe is stored in temporary
  memory by the OS, and is made available to the process that reads
  from it.

- Pipes are anonymous, i.e., there is no way to refer to them outside
  the process. The typical use case of pipes is for a parent process
  to create a pipe, and hand over endpoints to one or more
  children. Alternately, named pipes or FIFOs (First-In-First-Out)
  enable a process to create a pipe with a specified name, so that the
  endpoints of the pipe can be accessed outside the process as well.

- Message passing is another IPC mechanism provided by many
  operating systems. A process can create a message queue (much like a
  mailbox), and another process can send a message to this queue via
  the OS. A message queue is maintained as a linked list inside the
  kernel. Every message has a type, content, and other optional
  features like priority. System calls are available to create a
  message queue, and post and retrieve messages from the queue. As in
  the previous cases, blocking and non-blocking versions of the system
  calls are available. For example, when the message queue is full,
  the writing process can choose to block or return with an error
  message. Similarly, when the message queue is empty, the system call
  to read a message can block or return empty.