Additional considerations when using UNIX signal handling in MQI

Note these considerations when using UNIX signal handling.

Fastpath (trusted) applications

Fastpath applications run in the same process as IBM MQ and so are running in the multithreaded environment.

In this environment IBM MQ handles the synchronous signals SIGSEGV, SIGBUS, SIGFPE, and SIGILL. All other signals must not be delivered to the Fastpath application while it is connected to IBM MQ. Instead they must be blocked or handled by the application. If a Fastpath application intercepts such an event, the queue manager must be stopped and restarted, or it may be left in an undefined state. For a full list of the restrictions for Fastpath applications under MQCONNX, see Connect to a queue manager using the MQCONNX call.

MQI function calls within signal handlers

While we are in a signal handler, do not call an MQI function.

If you try to call an MQI function from a signal handler while another MQI function is active, MQRC_CALL_IN_PROGRESS is returned. If you try to call an MQI function from a signal handler while no other MQI function is active, it is likely to fail sometime during the operation because of the operating system restrictions where only selective calls can be issued from, or within, a handler.

For C++ destructor methods, which might be called automatically during program exit, you might not be able to stop the MQI functions from being called. Ignore any errors about MQRC_CALL_IN_PROGRESS. If a signal handler calls exit(), IBM MQ backs out uncommitted messages in sync point as usual and closes any open queues.

Signals during MQI calls

MQI functions do not return the code EINTR or any equivalent to application programs.

If a signal occurs during an MQI call, and the handler calls return, the call continues to run as if the signal had not happened. In particular, MQGET cannot be interrupted by a signal to return control immediately to the application. To break out of an MQGET, set the queue to GET_DISABLED; alternatively, use a loop around a call to MQGET with a finite time expiry (MQGMO_WAIT with gmo.WaitInterval set), and use your signal handler (in a nonthreaded environment) or equivalent function in a threaded environment to set a flag which breaks the loop.

In the AIX environment, IBM MQ requires that system calls interrupted by signals are restarted. When establishing your own signal handler with sigaction(2), set the SA_RESTART flag in the sa_flags field of the new action structure otherwise IBM MQ might be unable to complete any call interrupted by a signal.

User exits and installable services

User exits and installable services that run as part of an IBM MQ process in a multithreaded environment have the same restrictions as for fastpath applications. Consider these to be permanently connected to IBM MQ and so not using signals or non-threadsafe operating system calls.

VMS exit handlers

Users can install exit handlers for an IBM MQ application using the SYS$DCLEXH system service.

The exit handler receives control when an image exits. An image exit normally occurs when you call the Exit ($EXIT) or Force Exit ($FORCEX) service. The $FORCEX interrupts the target process in user mode. Then all user-mode exit handlers (established by $DCLEXH) begin to execute in reverse order of establishment. For more details on exit handlers and $FORCEX, see the VMS Programming Concepts Manual and the VMS System Services Manual.

If you call an MQI function from within an exit handler, the behavior of the function depends on the way the image was terminated. If the image was terminated while another MQI function is active, an MQRC_CALL_IN_PROGRESS is returned.

It is possible to call an MQI function from within an exit handler if no other MQI function is active and upcalls are disabled for the IBM MQ application. If upcalls are enabled for the IBM MQ application, it fails with the reason code MQRC_HCONN_ERROR.

The scope of an MQCONN or MQCONNX call is typically the thread that issued it. If upcalls are enabled, the exit handler runs as a separate thread and the connection handles cannot be shared.

Exit handlers are started within the interrupted context of the target process. It is up to the application to ensure that actions taken by a handler are safe and reliable, for the asynchronously interrupted context they are called from.