An Operating Systems Vade Mecum

Inter-process communication 307Port capabilities are much more complex to implement than port numbers. Beforewe introduced port capabilities, messages were uninterpreted streams of bytes. Delimitedports required the port manager to keep track of message boundaries, but otherwise itcould ignore the meaning of the bytes written to the port. The port manager must nowrealize when a port capability is being sent in a message so that it can remove the portcapability from the writer and later install it in the reader. If port capabilities arerepresented to the process as small integers, like port descriptors, then a port capabilitythat is sent in a message may have to be changed before it is received because the portdescriptornumber in the writer may already be in use for something else in the reader.The operating-system designer must also decide when to install the new port capabilityin the reader’s capability list. It could do so as soon as the message arrives at theport, but the reading process might not try to read the message for a long time. In fact, itmight terminate without reading the message, or the port might be destroyed by itsowner. In this case, the designer must decide whether the capability should be returnedto the writer or should be discarded.2.5 Semantics of Read and WriteWe have been using Read and Write as synchronous calls, and we have been assumingthat ports store data that have been written but not yet read. Neither of these choices isnecessary. First, we could have both calls initiate action but not block the calling process.The caller could discover completion by polling, by virtual interrupt, or by waitingexplicitly for completion later. Such asynchronous communication introduces new situationsthat must be given meaning. For example, what does it mean to call ClosePort ifthere is a ReadPort or WritePort still active? What does it mean to send a port capabilityin a message if that same port capability is still in use for some ReadPort or WritePortcall?Another alternative to synchronous write is to block the caller until a reply comesfrom the recipient. The Hysteresis Principle implies that if the reply is expected in lesstime than is needed for a process switch, the caller should not be preempted in favor ofanother process for that expected time in the hope that no process switch will be necessaryat all. The recipient would use a Reply service call to indicate that its message is aresponse to the previous one it received. Reply itself does not block. This approachrequires that the port allow messages in both directions.Second, we could relieve the port manager of the responsibility for bufferingunread data by keeping such data in the virtual space of the writer until they are read.This decision is independent of whether Read and Write are synchronous. An unbufferedwrite does not complete until its data have been read from the port. Until the unbufferedwrite completes, it is an error for the writer to modify the data being written because theport manager has not made a copy. It can be more efficient to implement unbufferedcommunication, since data don’t have to be copied as often.A process with several open ports may wish to read next from whichever one hasdata. Alternatively, it may wish to read from a particular port but ignore data on otherports for the time being. An even greater level of selectivity is to accept only messagesthat have a particular form but to ignore others for the time being. Operating systems