|
Signals
Does OS/400 support an asynchronous signals model? If so, how is it similar to or different from a UNIX model?
Yes, OS/400 supports an asynchronous signal model. The following answer applies to ILE signals. For information on PASE signals, see the related topic in the iSeries Information Center.
APIs are available to generate and handle both synchronous and asynchronous signal. The APIs are ANSI C functions signal() and raise() and X/Open APIs sigaction() and kill(). But, the support for these APIs on OS/400 differs from the usual behavior of signals on UNIX as follows:
- Interaction of ANSI C signal functions and X/Open signal functions: On UNIX the ANSI C signal functions and X/Open signal functions interact, i.e. the ANSI C function signal() operates on the process signal vector set by X/Open signal functions. Similarly, process signal blocking mask and signal action vectors are used when a signal is generated using ANSI C function raise(). On the other hand although OS/400 supports ANSI C and X/Open signal functions, the two types of functions do not interact. However, X/Open functions sigaction() and kill() provide the same type of capabilities as the ANSI C signal() and raise(). Further explanation and an example may be found on the threads Web site. The example uses threads, but the concepts apply irrespective of whether threads interfaces are used.
- Scope of signal controls (action vector, blocking mask, pending signals): On most UNIX systems, when a child process is started using fork() and exec() functions, the signal controls for the child process are inherited from the parent process. Changes made to the signal controls in either the parent or the child process are isolated to the process in which the change is made. Whereas, on OS/400, there can be two methods of calling another program. On one hand another process can be created using spawn() API and in this case signals will work as it would on UNIX using fork() and exec() calls. But, on the other hand a program can be called directly and the called program will run in the same process; in this case if the called program changes the process signal controls the changes remains in effect when called program returns to the caller. So, if the signal controls are changed in this case, those should be restored before returning to the caller.
- Mapping system detected error to signals: On UNIX systems, system detected errors are mapped to signal numbers. Whereas, on OS/400 system detected errors result in escape messages presented to the user. ANSI C signal model then maps escape messages to signal numbers, but the X/Open model does not, and system detected errors in this case should be handled using other mechanisms.
- Apart from the above main differences there are some minor differences in handling unexpected errors, in the siganal-catching function, termination action, and default actions on UNIX and OS/400.
[BACK]
|
|
|
