|
|
|
|
|
|
|
| ☜ | Asynchronous Event ProcessingDraft MDC Standard | ☞ | ||||
Asynchronous processing of an event (described below) occurs immediately following the event unless the event is blocked.
Blocked events are saved on one of two per-process event queues (one each for synchronous and asynchronous event classes). Each queue is only guaranteed to hold one event, though they may hold more. Events occurring when the queue is full are lost. Queued events are processed in the order they occurred once they are unblocked. It is possible that blocked events will not execute in the order they occurred if the events are of different event classes, and the event classes are separately unblocked in an order different from the order of occurrence of the events. Disabling an event class via the ASTOp command or by killing the appropriate node(s) in ^$Event or ^$Job removes all entries of that class from the event queue.
When a registered event is processed in the asynchronous model, the current value of $Test, the current execution level, and the current execution location are saved in an extrinsic frame on the PROCESS-STACK. The process then increments the block count on all event classes, and implicitly executes the command
Do handler
where handler is the registered event handler. Note that neither $Reference nor any other shared resource is stacked by this action. If the event handler changes the naked indicator, it may be advisable for it to first New $Reference. When the process control returns from the handler, the process decrements the block count on all event classes. The value of $Test and the execution level are restored, the process returns to the stacked execution location and the extrinsic frame is removed from the PROCESS-STACK.
|
|
|
|
|
|
|
Copyright © Standard Documents; 1977-2024 MUMPS Development Committee;
Copyright © Examples: 1995-2024 Ed de Moel;
Copyright © Annotations: 2003-2008 Jacquard Systems Research
Copyright © Annotations: 2008-2024 Ed de Moel.
Some specifications are "approved for inclusion in a future standard". Note that the MUMPS Development Committee cannot guarantee that such future standards will indeed be published.
This page most recently updated on 28-Nov-2011, 21:33:03.
For comments, contact Ed de Moel (demoel@jacquardsystems.com)