The persistence of IPC objects

Reprint: http://book.51cto.com/art/201006/207275.htm

UNIX Network Programming: 2nd edition. Volume 2nd, interprocess communication This book provides an in-depth overview of the various forms of inter-process communication, including messaging, synchronization, shared memory, and remote invocation (RPC). The book contains a lot of optimized source code to help readers deepen their understanding. These source codes can be downloaded free of charge from the Turing website book page. This section introduces the persistence of IPC objects.

1.3 The continuity of IPC objects

We can define the persistence of any type of IPC (persistence) as the length of time that an object of that type persists. Figure 1-2 shows the persistence of three types.

Figure 1-2 The continuity of the IPC object

(1) The IPC object that continues with the process (process-persistent) persists until the last process that opened the object closes the object. For example, pipelines and FIFO are such objects.

(2) The Kernel-persistent IPC object that persists with the kernel persists until the kernel re-bootstrap or explicitly deletes the object. For example, the message queue, semaphore, and shared memory area of System V are such objects. POSIX Message Queuing, semaphores, and shared memory areas must be at least persistent with the kernel, but can also be persisted with the file system, depending on the implementation.

(3) The IPC object that persists with the file system (filesystem-persistent) persists until the object is explicitly deleted. The object retains its value even if the kernel is re-raised. POSIX Message Queuing, semaphores, and shared memory areas that are implemented with a mapping file (not required) are persisted with the file system.

We must be careful when defining the continuity of an IPC object, because it is not always as it seems. For example, the data inside the pipeline is maintained in the kernel, but the pipeline has the continuity of the process rather than the persistence of the kernel: the last process that opens a pipe for reading closes the pipeline, and the kernel discards all the data and deletes the pipeline. Similarly, although FIFO has a name in the file system, they only have the persistence of the process, because the last process that opens a FIFO closes the FIFO, and the data in the FIFO is discarded.

Figure 1-3 summarizes the persistence of the various types of IPC objects that will be described in this book.

Figure 1-3 Persistence of various types of IPC objects

Note that there are no types of IPC in this list that are consistent with the file system, but we have said that there are three types of POSIX IPC that may have this continuity, depending on their implementation. Obviously, writing data to a file provides continuity with the file system, but this is usually not used as an IPC form. Most forms of IPC do not have the intention of continuing to exist after the system has been re-raised, because the process cannot continue to survive over the re-bootstrap. For a given form of IPC, it is required that the persistence of the file system may degrade its performance, while one of the basic design objectives of IPC is high performance.

The persistence of IPC objects