Analysis of communication system between NetBSD processes

Simple interprocess communication: Pipelines

Pipelines are the most traditional, simplest, and most efficient interprocess communication method in UNIX. The code for the NetBSD processing pipe is kern/sys_pipe.c, and its read-write function is mounted as a fileops of the file structure and is invoked when read (2), write (2).

Pipe creation

The response function of pipe (2) is real sys_pipe (). It first calls Pipe_create () two times, and the first request for a read Port will invoke Pipespace () to request a kernel address space to be used as a buffer (memory BSDSRCUVM, SUBMAP); The second time you apply for a write port, you do not request space. So we get two pipe structures, two ports for the pipe. It makes sense to put the buffer into the rpipe, because it makes the rest of the data readable even if the write port is turned off, and the write port (producer) writes the data without meaning if the read port (consumer) is turned off.

The next step for Sys_pipe () is to connect two ports and connect them to the file interface. We apply to read and write two corresponding file structure, fill in the return value; Then set the Pipe_peer to connect the pipe two ports. All the work is done.

Pipe Read

The response function for the pipe read is Pipe_read (). We entered a common loop, and if the requested read bytes were not completed, we continued to fetch the data in the buffer (XXX. Ignoring the nodirect, we have to make sure that our narrative can build a functioning system); Otherwise, if we do not receive the end of the file signal, and in the blocking read state, we have to wait, before waiting we have to wake up control Select/poll function or producer writer, otherwise our wait will never end.

Pipe Write

Let's look at the Pipe_write () function that the pipe writes. We first noticed a more depressing allegation of Rpipe and Wpipe. The point at which the wpipe is pointing is actually the rpipe created by pipe (2), because we have to write the data to the read port and let it read. We can also determine whether the current pipe is large enough to be written according to the size of the data, and can be expanded at any time.

We went into a cycle similar to the Pipe_read (). (XXX. Nodirect) The next process is similar, pay attention to the calculation of space, we tend to write data one-time, if not, we would rather wait.

Pipe shutdown

Pipe_close () only need to deal with the file interface, will f_data empty, the real pipe shutdown work by Pipeclose () completed. Here, we mainly want to modify the end of the state, tell it we are dying, pipe end, to point to the end of their pipe_peer domain empty. Then wake it up to the end of the read or write wait, and let it handle the event. Next, we return all the resources: the buffer (if it is the read port), the pipe structure, and the life of the port is over.

BSD interprocess communication: Socket

Please refer to Bsdsrcsocket

SYSTEMV IPC

SYSTEMV IPC is a communication mechanism brought about by commercial release SYSTEMV UNIX. It includes messages, shared storage areas, semaphores, and implements a good local process communication interface. The code implemented in NetBSD is kern/sysv_*.

Object identification

As a interprocess communication unit and allows multiple processes (not pipe two process point-to-point) to communicate, their communication units are clearly systematic and global. Objects of the three communication mechanisms have the same identity method: Each mechanism contains a table in which the table entries describe all instances of the mechanism; Each table entry has a user-selected key, and each process can get a communication object instance through key to communicate with each other. Each communication object instance corresponds to a globally unique identifier for real communication.

Consider that the global identifier is the position of the object instance in the table. We're going to have a situation where a program communicates with an ID, but the corresponding communication instance of this ID may have been undone and replaced by another communication entity, and the program doesn't know anything about it and continues to operate, which can have disastrous consequences. Our solution is to add a _seq domain, each request an instance of its _seq domain plus 1, we return the identifier is _SEQ * 65536 + instance in the table position, so that does not produce this confusion.

Each IPC structure has a permission table entry whose permission settings are similar to that of a file, through which we can limit the permissions that some processes communicate with each other.

The above identification method is described in struct ipc_perm, with each IPC object structure carrying a ipc_perm.

Message Queuing (Messages queue)

The object structure of the message is described in struct msqid_ds, and the global control structure is struct msginfo.