Abort Handlers

A variety of microkernel system calls can be used to block a current thread when a request cannot be satisfied immediately or has to await a particular event. Thread blocking and wakeup operations are performed by microkernel features through the invocation of a microkernel internal interface.

A thread can be forced to exit the blocked state. Subsystem managers might need to awaken blocked threads prematurely to enable them to perform their function (to process asynchronous signals, for example). When a thread is blocked, it may be ABORTABLE, depending on the blocking primitive invoked and/or the arguments of this invocation.

The threadAbort() primitive forces a thread which is blocked in an ABORTABLE state to be awakened. Generally, a corresponding blocking call returns a specific error code, indicating an abort.

Because the invoker of threadAbort() may not know whether the thread is currently blocked or not, the microkernel will define the behavior of the threadAbort() call if the thread is active.

Therefore, the effect of threadAbort() depends on the state of the thread.

• If a thread is blocked into an ABORTABLE microkernel call without an abort handler for its home actor, the aborted thread returns with the K_EABORT error code. If an abort handler is set, the error code is not returned and the abort handler is invoked.

• If a thread is not blocked in an ABORTABLE state, the abort event will be recorded. The thread is said to be in an ABORTED state. The abort will be handled later.

When a thread is in an ABORTED state, it handles the abort if either of the following situations occurs:

• The thread executes in its home actor (internal mode). In this case, the thread can execute an abort handler. Supervisor actors can attach abort handlers to other actors to trap the entry of threads of actors in an ABORTED state. If this type of handler is attached to the thread's home actor, it is invoked as soon as the thread executes in its home actor while in the ABORTED state.

• If the thread was executing in a different actor or a microkernel call when aborted, and an abort handler is in effect, the handler will be invoked as soon as the thread returns to its home actor execution environment.

After the abort handler has been executed, the abort is considered to have been handled:

• The thread invokes an ABORTABLE blocking primitive. In this case, the primitive returns with the K_EABORT error code. The abort has been handled.

• The thread invokes the threadAborted() microkernel primitive. This primitive returns its current state (aborted or not) and clears the state.

Asynchronous execution control operations (threadAbort()) take effect immediately only if the target thread is currently running in internal mode, that is, if its current execution actor matches its home actor. In the case, where the thread has changed its execution actor (through a microkernel call, trap, or other) , the operation is deferred until the execution actor is reset to the home actor, on return from the microkernel call or trap, for example. Deletion of a thread is also considered an asynchronous control operation in this sense. Thus, a thread is immune from deletion (except if it deletes itself) when its execution actor is changed for a trap or other cross-actor invocation. It is deleted only when it returns to its home actor.