On Mon, Oct 5, 2015 at 2:52 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
On 02/10/15 13:05, Daπid wrote:
Have you tried asking Python-dev for help with this? Hopefully they would have some weight there.
It seems both GCC dev and Apple (for GCD and Accelerate) has taken a similar stance on this. There is tiny set of functions the POSIX standard demands should work on both sides of a fork without exec, but OpenMP, GCD, BLAS or LAPAPCK are not included. As long as there is no bug, it is hard to convince them to follow Intel and allow fork-based multiprocessing.
To be clear, the GCC devs are open to supporting fork+OpenMP in principle, they just aren't willing to do it in a way that risks breaking strict POSIX or OpenMP compatibility. But that isn't even the problem -- we have a patch that is strictly compatible with POSIX and OpenMP. The problem is that with the patch, the cases that would formerly have deadlocked instead leak some memory. This is not a big deal IMO for a variety of reasons (mostly that a one time leak per child process is tiny, esp. compared to the current situation with deadlocks), but it means the patch needs someone serious in the GCC community to take a look at it carefully, understand what the tradeoffs actually are, and make a judgement call. And so far we haven't convinced anyone to do this. -n -- Nathaniel J. Smith -- http://vorpus.org