IPC Identifiers and Client-Server Applications

930
Chapter 45
Suppose a client engages in an extended dialogue with a server, with multiple
IPC operations being performed by each process (e.g., multiple messages
exchanged, a sequence of semaphore operations, or multiple updates to shared
memory). What happens if the server process crashes or is deliberately halted and
then restarted? At this point, it would make no sense to blindly reuse the existing
IPC object created by the previous server process, since the new server process has
no knowledge of the historical information associated with the current state of the
IPC object. (For example, there may be a secondary request within a message
queue that was sent by a client in response to an earlier message from the old
server process.)
In such a scenario, the only option for the server may be to abandon all existing
clients, delete the IPC objects created by the previous server process, and create new
instances of the IPC objects. A newly started server handles the possibility that a pre-
vious instance of the server terminated prematurely by first trying to create an IPC
object by specifying both the 
IPC_CREAT
and the 
IPC_EXCL
flags within the get call. If
the get call fails because an object with the specified key already exists, then the
server assumes the object was created by an old server process; it therefore uses the
IPC_RMID
ctl operation to delete the object, and once more performs a get call to create
the object. (This may be combined with other steps to ensure that another server
process is not currently running, such as those described in Section 55.6.) For a
message queue, these steps might appear as shown in Listing 45-1.

tải về 6.93 Mb.

Chia sẻ với bạn bè của bạn: