Ronald Oussoren <ronaldousso...@mac.com> added the comment:
> 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/> ---------- versions: +Python 3.10, Python 3.9 -Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31818> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
