Author barry
Recipients barry, davin, gregory.p.smith, josh.r, kapilt, lukasz.langa, miss-islington, ned.deily, pablogsal, pitrou, ronaldoussoren, tdsmith, vstinner
Date 2019-05-29.16:20:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <9AC32CA5-FBEB-491A-8EA1-F108C86EBB30@python.org>
In-reply-to <1559089293.33.0.822605654905.issue33725@roundup.psfhosted.org>
Content
On May 28, 2019, at 17:21, STINNER Victor <report@bugs.python.org> wrote:
> 
> 
> STINNER Victor <vstinner@redhat.com> added the comment:
> 
>> To be clear, what is unsafe on macOS (as of 10.13, but even more so on 10.14) is calling into the Objective-C runtime between fork and exec.  The problem for Python is that it’s way too easy to do that implicitly, thus causing the macOS to abort the subprocess in surprising ways.
> 
> Do only a few Python module use the Objective-C runtime? Or is it basically "everything"?
> 
> If it's just a few, would it be possible to emit a warning or even an exception if called in a child process after fork?

I think it’s hard to know, but I found it through a path that lead from requests to _scproxy.c.  Here’s everything I know about the subject:

https://wefearchange.org/2018/11/forkmacos.rst.html

So yes, it’s theoretically possible to do *some* between fork and exec and not crash, and it’s of course perfectly safe to call exec pretty much right after fork.  It’s just hard to know for sure, and there are surprising ways to get into the Objective-C runtime.

I think we won’t be able to work around all of Apple’s choices here.  Documentation is the best way to handle it in <=3.7, and changing the default makes sense to me for 3.8.
History
Date User Action Args
2019-05-29 16:20:31barrysetrecipients: + barry, gregory.p.smith, ronaldoussoren, pitrou, vstinner, ned.deily, lukasz.langa, josh.r, tdsmith, davin, pablogsal, miss-islington, kapilt
2019-05-29 16:20:31barrylinkissue33725 messages
2019-05-29 16:20:31barrycreate