cma_alert_enable_asynch

Enables asynchronous alert delivery to the current thread.

Syntax

cma_alert_enable_asynch();

C Binding

#include 


void
cma_alert_enable_asynch (void);

Arguments

None

Description

To allow restoration of the previous alert state when asynchronous cancelability is no longer needed, call cma_alert_disable_asynch to obtain the current alert state prior to calling this routine.

This routine is alertable. If an alert is pending for the current thread, and alert delivery is not currently disabled, then the pending alert is delivered before this routine returns.

Asynchronous delivery of alerts means that the cma_e_alerted exception can be raised at any point in the code where an interrupt can occur. The exception could potentially be raised in the middle of a hardware instruction, if that is permitted by the machine.

Asynchronous delivery of alerts is not appropriate over regions of code where resources are being allocated, or when invariants are being modified. It is difficult to determine exactly where an exception was raised within such a region. Usually this makes it very difficult (and often impossible) to properly release resources or restore invariants should an alert be delivered.

External routines often do not function correctly with asynchronous delivery of alerts enabled. Also, most existing code will not be able to cope with asynchronous alerts. Note that none of the general run-time routines are safe. None of the DECthreads library routines are safe except cma_alert_restore and pthread_setasynccancel. It is always safest to disable asynchronous delivery before calling any external routine from a region of code where asynchronous delivery of alerts has been enabled.

The best application for asynchronous alert delivery is when the program needs to perform a long computation that does not affect program invariants and where adding calls to cma_alert_test is impractical or would slow down the computation.

Enabling asynchronous delivery over such a region of code allows the code to be highly responsive to abort requests without complicating or slowing the computation.

For example, a matrix multiply has only two real states: either the product was created successfully, or it was not. Generally, there is no need to know about the state of the product if it could not be completed. A matrix multiply can also take a very long time and should, therefore, be alertable. But because it involves several nested loops whose limits are parameters, it is not obvious where to place calls to cma_alert_test within it, or desirable to do so. To ensure that the matrix multiply is alertable, perform the following steps:

1. Set a flag indicating that the product is not available.

2. Disable asynchronous alerts to get the prior state.

3. Enable asynchronous delivery of alerts.

4. Perform multiplication (which may take a long time but is alertable).

5. Restore prior alert state.

6. Set a flag indicating the product is available.

See Example E-1 for more information.

Exceptions