Threaded applications

A thread is considered to be connected to IBM® MQ from MQCONN (or MQCONNX) until MQDISC.

Synchronous signals

Synchronous signals arise in a specific thread.

UNIX and Linux® systems safely allow the setting up of a signal handler for such signals for the whole process. However, IBM MQ sets up its own handler for the following signals, in the application process, while any thread is connected to IBM MQ:

SIGBUS
SIGFPE
SIGSEGV
SIGILL

If you are writing multithreaded applications, there is only one process-wide signal handler for each signal. When IBM MQ sets up its own synchronous signal handlers it saves any previously registered handlers for each signal. After IBM MQ handles one of the signals listed, IBM MQ attempts to call the signal handler that was in effect at the time of the first IBM MQ connection within the process. The previously registered handlers are restored when all application threads have disconnected from IBM MQ.

Because signal handlers are saved and restored by IBM MQ, application threads must not establish signal handlers for these signals while there is any possibility that another thread of the same process is also connected to IBM MQ.

Note: When an application, or a middleware library (running as part of an application), establishes a signal handler while a thread is connected to IBM MQ, the application's signal handler must call the corresponding IBM MQ handler during the processing of that signal.

When establishing and restoring signal handlers, the general principle is that the last signal handler to be saved must be the first to be restored:

When an application establishes a signal handler after connecting to IBM MQ, the previous signal handler must be restored before the application disconnects from IBM MQ.
When an application establishes a signal handler before connecting to IBM MQ, the application must disconnect from IBM MQ before restoring its signal handler.

Note: Failure to observe the general principle that the last signal handler to be saved must be the first to be restored can result in unexpected signal handling in the application and, potentially, the loss of signals by the application.

Asynchronous signals

IBM MQ does not use any asynchronous signals in threaded applications unless they are client applications.

Additional considerations for threaded client applications

IBM MQ handles the following signals during I/O to a server. These signals are defined by the communications stack. The application must not establish a signal handler for these signals while a thread is connected to a queue manager:

SIGPIPE (for TCP/IP)