This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author barry
Recipients barry, davin, kapilt, miss-islington, ned.deily, pitrou, ronaldoussoren, vstinner
Date 2018-12-13.02:24:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <DBC4E524-ADD8-4C17-AC55-945F66ECFA1E@python.org>
In-reply-to <1544666393.95.0.788709270274.issue33725@psf.upfronthosting.co.za>
Content
On Dec 12, 2018, at 17:59, Ned Deily <report@bugs.python.org> wrote:
> 
> Ned Deily <nad@python.org> added the comment:
> 
>> Would it be safe to run the multiprocessing tests on recent macOS with the OBJC_DISABLE_INITIALIZE_FORK_SAFETY environment variable set?
> 
> See Ronald's reply above in msg331101. I believe his point is that there is nothing you can do to make this safe. And it's not a new problem with 10.14 or 10.13. What is new is that Apple is trying to more forcefully make you aware of the danger by causing the runtime to try to catch and crash these cases earlier rather than permit them to perhaps silently cause failures later.

In my experiments at least, setting the env var *does* prevent the crash, but it doesn’t avoid the undefined semantics (i.e. what happens when the ObjC runtime is called at that point?) and I fully expect that Apple will remove that bandaid at some point.

The other key thing is that I don’t believe you can set the env var *in process* and have it take effect after the fork.  It must be set before the parent process starts.  So that probably makes it less useful for the multiprocessing tests by itself.
History
Date User Action Args
2018-12-13 02:24:45barrysetrecipients: + barry, ronaldoussoren, pitrou, vstinner, ned.deily, davin, miss-islington, kapilt
2018-12-13 02:24:44barrylinkissue33725 messages
2018-12-13 02:24:43barrycreate