The outcome is undefined if a thread that executes an MPI-/ call is
cancelled (by another thread), or if a thread catches a signal while
executing an MPI-/ call.
However, a thread of an MPI-/ process may terminate, and may catch
signals or be cancelled by another thread when not executing MPI-/ calls.
-
- Rationale.
Few C library functions are signal safe, and many have cancellation
points -- points where the thread executing them may be cancelled. The
above restriction simplifies implementation (no need for the MPI-/
library to be ``async-cancel-safe'' or ``async-signal-safe.'' (End of rationale.)
-
- Advice to users.
Users can catch signals in separate, non-MPI-/ threads (e.g., by
masking signals on MPI-/ calling threads, and unmasking them in one or
more non-MPI-/ threads).
A good programming practice is to have a distinct thread blocked
in a call to sigwait for each user expected signal that may occur.
Users must not catch signals used by the MPI-/ implementation; as
each MPI-/ implementation is required to document the signals used
internally, users can avoid these signals.
(End of advice to users.)
-
- Advice
to implementors.
The MPI-/ library should not invoke library calls that are
not thread safe, if multiple threads execute.(End of advice to implementors.)
MPI-Standard for MARMOT