GDSX Manual

Service Routines
Extended General Device Support (GDSX) Manual134303
8-77
^SIGNALTIMEOUT
Here is an example:
At this point, the task may obtain the -22 system message by a call on ^AWAITIO.
^SIGNALTIMEOUT
This procedure sets a timer to a given number of units of elapsed time. When the time
expires, the calling task receives an indication in the form of a system message (-22) on
$RECEIVE for either a DEVICE^HANDLER task or a LINE^HANDLER task.
Except for the following considerations, the syntax, condition code settings, and
considerations regarding this procedure are the same as the counterpart in the Guardian
Procedure Calls Reference Manual.
Considerations
Because the working stack images of tasks are swapped to and from an extended
data segment during I/O operations, I/O must be performed to and from global
buffers.
The tag parameter of ^SIGNALTIMEOUT holds the address of the IOCB allocated
when ^SIGNALTIMEOUT or ^SIGNALINTERRUPT was called. It is an INT(32)
variable.
^SIGNALTIMEOUT sets CCL if an IOCB cannot be allocated.
The entry point ^SIGNALINTERRUPT within ^SIGNALTIMEOUT may be used to
modify the handling of the resultant system message. See the preceding description
of the ^SIGNALINTERRUPT procedure.
Examples
1. This example uses ^AWAITIO[X] to handle a timeout:
CALL ^READUPDATE ( 0 );
IF <> THEN CALL DEBUG; ! DO ERROR HANDLING
CALL ^SIGNALTIMEOUT ( 100D, , , IOCBADDR );
IF < THEN
BEGIN
! NO IOCB AVAILABLE
Time 0: ^SIGNALINTERRUPT is called with timeout-value = 5
seconds.
Time 2 seconds: GETLOCALPOOL is called to obtain buffer space with
timeout-value = 6 seconds. Space is not currently available.
Time 5 seconds: Signal pops. The task is redispatched and GETLOCALPOOL
returns 0, indicating a timeout, even though the task had only
waited 3 seconds for buffer space.
Caution. When using WAIT^EVENT to detect timeout events resulting from calls to
^SIGNALTIMEOUT, release the IOCB allocated by TSCODE, or the IOCB table may eventually
be exhausted, generating an error 32. See the examples following.