Block signal delivery to OpenBLAS-spawned threads

[peadar]

Otherwise non-threaded applications may use signals in a way that is currently affected by OpenBLAS launching threads.

For example, it is not uncommon for an application main loop to block signals when busy, then unblock those signals while waiting for IO. (see the sigmask argument to ppoll(2))

Signals that arrive during ppoll(2) will interrupt the system call, and allow the application to handle any consequences of that signal arriving. Normally (in a single threaded process), on delivery of an externally generated signal such as SIGALRM, SIGCHLD, SIGIO the main loop will be awoken. If the thread is otherwise busy, then the signal will be maintained as pending, and will be delivered when the application next enters its idle state (eg ppoll), unblocking signals again.

OpenBLAS creates threads during initialization. Such threads inherit their signal masks from the thread that creates them, and, if that loading happens very early in the lifetime of a process, all signals are nominally unblocked in the these threads

Later, if the "main" thread is running with signals blocked when a signal is sent to the process, the kernel will deliver it to another thread in the process if it is not currently blocking that signal, in our case, to one of the OpenBLAS threads.

This means that by creating threads with open signal masks, OpenBLAS is potentially interfering with the normal operation of programs that are otherwise non-threaded.

Instead, we should block all signals before starting new threads from blas_thread_init, and then restore the signal mask as it was, so the launched threads do not participate in signal delivery and processing.