Guardian Programmer's Guide

Communicating With Processes
Guardian Programmer’s Guide — 421922-014
6 - 23
Checking for Canceled Messages
Checking for Canceled Messages
Typically, a server processes messages from other processes as follows:
1. The server reads a message from its $RECEIVE file.
2. The server performs some processing in response to the message.
3. The server replies to the process that sent the message.
Between the time the server reads the message using the READUPDATE[X]
procedure and the time the server replies to the message using the REPLY[X]
procedure, the message could be canceled for any of the following reasons:
•
The process that sent the message calls CANCEL, CANCELREQ, FILE_CLOSE_,
or certain forms of AWAITIO[X].
•
The process that sent the message stops executing (for example, by calling
PROCESS_STOP_).
A typical use for message cancellation is when a requester process wants a high-
priority request performed but the server is taking a long time to process a lower-
priority request. The requester can ask to have the old request canceled so that the
new request can proceed.
For example, a server process might wait indefinitely for input from a terminal or for a
lock on a file. If the requester wants to have another request processed that conflicts
with the long running request—like printing some text to the same terminal—then it can
send a cancellation message to the server before sending the new request. Logic in
the message system prevents the new request from overtaking the cancellation
message and reaching the server first.
Even if a message that has been read using READUPDATE[X] is canceled, the server
must still reply to that message by calling REPLY[X]. The response by the server is an
application design issue that depends on the relationship between the requester and
server. Typically, a requester that cancels a request expects that the original request
may not be fully completed, therefore, the server need not perform any processing for
that message. Moreover, a process that cancels a request and then sends a new
request probably does not want the old request to hold up execution of the new
request. Thus, the server process can avoid unnecessary processing by ensuring that
a message has not been canceled before processing that message.
A process can check for canceled messages in two ways:
•
By checking for system message number -38 (cancellation messages) in its
$RECEIVE file. This method is appropriate only when the server handles multiple
requests concurrently.
•
By calling the MESSAGESTATUS procedure.
Note. It is never required to cancel a message. Only if a request takes a long time to process
is it appropriate to cancel that request.