openmp/pthreads and fork...

[Isaac Dunham <ibid.ag@gmail.com>]

Hello,
I've been packaging OpenBLAS for Alpine Linux, and an issue came to my
attention:
OpenBLAS (optionally) uses pthreads or OpenMP, and OpenMP uses pthreads.
OpenBLAS implements the BLAS (Basic Linear Algebra Subprograms) API/ABI,
like ATLAS, MKL, and so on.
Some programs that use BLAS will fork(); python is one of these.
With OpenBLAS, this had caused "random" segfaults due to use of threads
by the library both before and after the fork.
The OpenBLAS issue is here:
https://github.com/xianyi/OpenBLAS/issues/294

They worked around this using pthread_atfork() to cleanup before the fork().
I see some claims that calling any pthread functions in the child would be
UB, so I'm wondering about a few things:
-Is the last-mentioned claim correct?
-What is musl's behavior?
-How correct, and how likely to work with musl, is the fix for libgomp
mentioned here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035
(and for that matter, the equivalent workaround referred to in OpenBLAS
issue 294)?
-Is there a safe (non-crashing) way to use/write libraries that might or
might not be built with threading--whether POSIX-specified or just
"working with musl" ?

Thanks,
Isaac Dunham

PS: OpenBLAS almost built out of the box; the only issue was use of
get_nprocs(), a GNU extension equivalent to sysconf(_SC_NPROCESSORS_ONLN).
When I submitted a patch, it was merged in about 2 hours.
I've been building with NO_AFFINITY=1 ... TARGET=ATOM.