Author ronaldoussoren
Recipients Mirko Friedenhagen, barry, ned.deily, ronaldoussoren, vstinner
Date 2020-10-20.08:53:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1603184008.34.0.635564435654.issue31818@roundup.psfhosted.org>
In-reply-to
Content
> My understanding is that this is specifically a problem with the Objective-C 
> runtime that _scproxy.c accesses.  The runtime is not thread safe and 
> whereas in earlier versions of macOS, it silently failed, now macOS is 
> explicitly aborting the process.

Note quite, the ObjC runtime is thread safe (and so are most high-level APIs) but a number of APIs use threads or process-level state that needs to be reset in a child proces and isn't. To phrase this in CPython API: Apple doesn't use the equivalent of PyOS_AfterFork_Child in a number of places where this would be needed to be able to use APIs in child processes.  Instead of that recentish version of macOS just detect that the process-id changed and bail out.

This is a quality of implementation issue, and could also happen on other platforms (locks held across fork(), ...), especially when using threads. 

"A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called."
<https://pubs.opengroup.org/onlinepubs/9699919799/>
History
Date User Action Args
2020-10-20 08:53:28ronaldoussorensetrecipients: + ronaldoussoren, barry, vstinner, ned.deily, Mirko Friedenhagen
2020-10-20 08:53:28ronaldoussorensetmessageid: <1603184008.34.0.635564435654.issue31818@roundup.psfhosted.org>
2020-10-20 08:53:28ronaldoussorenlinkissue31818 messages
2020-10-20 08:53:28ronaldoussorencreate