GDSX Manual

LINE^HANDLER Example, Design
Extended General Device Support (GDSX) Manual–134303
7-3
Intertask Communication—LINE^HANDLER
Perspective
See Figure 7-2 for an illustration of how a WRITEREAD request is handled in a typical
GDSX process with a LINE^HANDLER. In this figure, text that crosses the line
between the “D^H TASK“ and “L^H TASK“ columns applies to TSCODE, not to the
DEVICE^HANDLER or LINE^HANDLER. Note that each interprocess request
submitted by the application requester that results in an I/O operation implemented by
the DEVICE^HANDLER does not go directly to the terminal. The I/O operation is sent
first to the LINE^HANDLER task associated with the terminal.
Intertask Communication—LINE^HANDLER
Perspective
This example is more complex than the DEVICE^HANDLER example, because a
LINE^HANDLER must be multithreaded, simultaneously handling several types of
events. For example, a LINE^HANDLER might handle I/O to the LINE, intertask
communication with DEVICE^HANDLER tasks, resource availability messages,
messages passed directly from $RECEIVE by TSCODE, and cancellation messages
from TSCODE. In addition, to handle these asynchronous events efficiently, a
LINE^HANDLER cannot use the ^AWAITIO[X] procedure, which would test only for
I/O completions.
Instead of using ^AWAITIO[X], a LINE^HANDLER task checks for I/O completions
and other events with the WAIT^EVENT procedure. WAIT^EVENT returns an
indication of the type of event that occurred. The ^LISTEN procedure may be used to
get the address of any associated IOCB, which in turn can be used to locate the message
buffer (as was done in the previous section’s control block tracing exercise). TSCODE
does not move data from an IOCB to a message buffer when WAIT^EVENT is called as
it does when ^AWAITIOX(DOLR^RCV, ...) is called after a call to ^READUPDATE in
a DEVICE^HANDLER .