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 ronaldoussoren
Recipients ezwelty, ned.deily, pitrou, ronaldoussoren, terry.reedy
Date 2018-07-15.18:54:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <25F35AB3-8194-4464-93E0-A1D4DB6D54DE@mac.com>
In-reply-to <1531593049.35.0.56676864532.issue33111@psf.upfronthosting.co.za>
Content
As I mentioned in msg314304 this is almost certainly expected behavior on macOS because Apple’s GUI frameworks are not fork()-safe.  There is nothing we can do about this other than changing the default spawn mechanism for multiprocessing on macOS. 

--
On the road, hence brief. 

Op 14 jul. 2018 om 19:30 heeft Terry J. Reedy <report@bugs.python.org> het volgende geschreven:

> 
> Terry J. Reedy <tjreedy@udel.edu> added the comment:
> 
> On MacOS, 3.7.0 is compiled for and the installer loads tcl/tk 8.6.8.  The same is true for the 3.6.6 64-bit installer.  Do tkinter and multiprocessing work together better with these installations?
> 
> I want to consider using multiprocessing and pipes instead subprocess and socket for IDLE's user-code execution process, started from and communicating with the initial tkinter gui process.  idlelib.run, which runs in the execution process to communicae with the gui process and supervise running user code, imports tkinter.  Besides which, users have to be able to import tkinter in their programs.
> 
> ----------
> nosy: +pitrou
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue33111>
> _______________________________________
History
Date User Action Args
2018-07-15 18:54:30ronaldoussorensetrecipients: + ronaldoussoren, terry.reedy, pitrou, ned.deily, ezwelty
2018-07-15 18:54:30ronaldoussorenlinkissue33111 messages
2018-07-15 18:54:30ronaldoussorencreate