The Asynchronous Signal Model (ASM) is used when the SYSIFCOPT(*ASYNCSIGNAL) option is specified on the the compilation. It is inteded for campatibility with applications ported from the UNIX operating system. In the ASM model, the signal() and raise() functions are implemented using the OS/400 Signal APIs described in the API topic under the Programming heading in the Information Center.
OS/400 exceptions sent to an ASM program are converted to asynchronous signals. The exceptions are processed by an asynchronous signal handler
Modules compiled to use the ASM can be intermixed with modules using the Original Signal Model (OSM) in the same processes, programs, and service programs. This is true even when SYSIFCOPT(*ASYNCSIGNAL) is not specified on the compilation command for programs compiled with the OSM. There are several differences between the two signal models:
Asynchronous signals are not mapped to exceptions, and are not handled by signal handlers registered under the OSM. Under the ASM, the exceptions are received and handled by the _C_async_exception_router function, which maps the exception to an asynchronous signal, and uses the SNDSIG MI instruction to raise an asynchronous signal. An ASM signal handler receives control from the OS/400 asynchonous signal component.
When an OSM program raises a signal, the generated exception percolates up the invocation stack until it finds an exception monitor. If the prior invocation is an OSM function, the _C_exception_router catches the exception and performs the OSM signal action. The ASM signal handler does not receive the signal.
If the prior invocation is an ASM function, the _C_async_exception_router handles the exception, maps to an asynchronous signal, and raises it using the MI SNDSIG instruction. The handling of the asynchronous signal then depends on the asynchronous signal vector and mask state of the thread, as defined in the OS/400 Signal Management topic.
If the OSM program raising the signal is running in the same activation group with the ASM program, the exception will be mapped to an asynchronous signal using the mapping described previously. The signal ID is preserved when the exception is mapped to a signal. So, signal handlers registered with the asynchronous signal model will be able to receive signals generated under the original signal model. Use this approach to integrate two programs using different signal models.
If a program or service program using the OSM is running a different activation group, any signal that is unmonitored in that activation group will cause the termination of that program and activation group. The unmonitored signal is then percolated to the calling program as a CEE9901 exception. The CEE9901 exception is mapped to a SIGSEGV asynchronous signal.
(C) Copyright IBM Corporation 1992, 2006. All Rights Reserved.