[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Aug 2014 22:56:51 -0700
From: Isaac Dunham <ibid.ag@...il.com>
To: musl@...ts.openwall.com
Subject: openmp/pthreads and fork...
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.
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.
