☜	ABLOCK M[UMPS] by Example					☞

Approved for inclusion in a future M[UMPS] Language standard, as a part of the "event processing" extensions.

This command "blocks" an event. When an event is "blocked" for a process, that process will not be interrupted to execute code for that event when one occurs. If a registered event occurs for a process while it is "blocked", it will be queued for later processing. If an un-registered event occurs while it is "blocked", it will be ignored. Events are registered by assigning values to nodes in structured system variable ^$Job. Events are "un-blocked" using the command AUnblock.

Note: every ABlock command increases the "block" counter for an event. In order to "un-block" an event, every AUnblock command decreases that counter. Events are only "un-blocked" when the value of that counter is equal to zero.

The example below assumes that the underlying system is capable of receiving a warning of imminent power loss from an "un-interruptible power supply" which is providing the system with power and that the system is capable of responding by generating an event. The event class in this case is "POWER", and the corresponding event-ID is equal to 1. A given process may want to execute a routine ^SHTDN to save its essential information if and when such an event occurs. The following code sample indicates how such an event can be processed asynchronously:

 ; Register the procedure to process a POWER event
 ; for this process
 Set ^$Job($Job,"EVENT","POWER",1)="^SHTDN"
 ; Enable this event for
 ; Asynchronous Event Processing
 ASTArt "POWER"

From this point on, if the un-interruptible power supply generates the POWER event, this process will transfer control (asynchronously) to the routine ^SHTDN.

Now, keep in mind that event handling routines implicitly invoke an argumentless ABlock command when they are entered as the result of an event. When they exit, there is an implicit AUnblock command for all events. In other words, while you’re processing an event, you’re temporarily blind to any events that might happen; this prevents getting yourself into an un-ending eddy of nested events. So, if this process also has handlers for other event classes that should be interrupted by POWER events, those event handlers should contain code like:

 ; Enable POWER events in this handler
 AUnblock "POWER"
 ... ; the body of the event handles goes here
 ; Now block POWER events again, so that the
 ; implicit AUNBLOCK won’t distort the "block-count"
 ABlock "POWER"
 Quit

The above example shows processing of events of the class "POWER", The "event processing extension" defines the event classes "COMM" (events related to devices), "HALT" (events that are generated when processes terminate), "IPC" (events communicated by other processes), "INTERRUPT" (events that are generated when a process is interrupted in an implementation-specific fashion), "POWER" (events generated when loss of electrical power is imminent), "TIMER" (events that are generated when a timer’s waiting time has elapsed) and "USER" (events that are generated through the ETrigger command).

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.

The information in this page is NOT authoritative and subject to be modified at any moment.
Please consult the appropriate (draft) language standard for an authoritative definition.

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 15-Nov-2023, 13:21:39.

For comments, contact Ed de Moel (demoel@jacquardsystems.com)