Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Aug 2014 22:56:51 -0700
From: Isaac Dunham <>
Subject: openmp/pthreads and fork...

I've been packaging OpenBLAS for Alpine Linux, and an issue came to my
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:

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:
(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" ?

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.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.