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.
Signed-off-by: Peter Edwards <peadar@arista.com>