UNIX and Linux signal handling
This does not apply to IBM MQ for z/OS or IBM MQ for Windows.
In general, UNIX, Linux and IBM i systems have moved from a nonthreaded (process) environment to a multithreaded environment. In the nonthreaded environment, some functions could be implemented only by using signals, though most applications did not need to be aware of signals and signal handling. In the multithreaded environment, thread-based primitives support some of the functions that used to be implemented in the nonthreaded environments using signals.
In many instances, signals and signal handling, although supported, do not fit well into the multithreaded environment and various restrictions exist. This can be problematic when we are integrating application code with different middleware libraries (running as part of the application) in a multithreaded environment where each is trying to handle signals. The traditional approach of saving and restoring signal handlers (defined per process), which worked when there was only one thread of execution within a process, does not work in a multithreaded environment. This is because many threads of execution could be trying to save and restore a process-wide resource, with unpredictable results.
- Unthreaded applications
Each MQI function sets up its own signal handler for the signals. Users' handlers for these are replaced for the duration of the MQI function call. Other signals can be caught in the normal way by user-written handlers.- Threaded applications
A thread is considered to be connected to IBM MQ from MQCONN (or MQCONNX) until MQDISC.- Additional considerations when using UNIX signal handling in MQI
Note these considerations when using UNIX signal handling.Parent topic: UNIX and Linux considerations