[issue40379] multiprocessing's default start method of fork()-without-exec() is broken

2021-04-30 Thread Itamar Turner-Trauring
Itamar Turner-Trauring added the comment: Given people's general experience, I would not say that "fork" works on Linux either. More like "99% of the time it works, 1% it randomly breaks in mysterious way". -- ___ Py

[issue40379] multiprocessing's default start method of fork()-without-exec() is broken

2021-04-30 Thread Itamar Turner-Trauring
Itamar Turner-Trauring added the comment: This change was made on macOS at some point, so why not Linux? "spawn" is already the default on macOS and Windows. -- ___ Python tracker <https://bugs.python.o

[issue40379] multiprocessing's default start method of fork()-without-exec() is broken

2020-11-06 Thread Itamar Turner-Trauring
Itamar Turner-Trauring added the comment: Another person with the same issue: https://twitter.com/volcan01010/status/1324764531139248128 -- nosy: +itamarst2 ___ Python tracker <https://bugs.python.org/issue40

[issue40379] multiprocessing's default start method of fork()-without-exec() is broken

2020-05-05 Thread Itamar Turner-Trauring
Itamar Turner-Trauring added the comment: Just got an email from someone for whom switching to "spawn" fixed a problem. Earlier this week someone tweeted about this fixing things. This keeps hitting people in the real world. -- ___ Pyth

[issue40379] multiprocessing's default start method of fork()-without-exec() is broken

2020-04-24 Thread Itamar Turner-Trauring
Itamar Turner-Trauring added the comment: Looks like as of 3.8 this only impacts Linux/non-macOS-POSIX, so I'll amend the above to say this will also make it consistent with macOS. -- ___ Python tracker <https://bugs.python.org/issue40

[issue40379] multiprocessing's default start method of fork()-without-exec() is broken

2020-04-24 Thread Itamar Turner-Trauring
New submission from Itamar Turner-Trauring : By default, multiprocessing uses fork() without exec() on POSIX. For a variety of reasons this can lead to inconsistent state in subprocesses: module-level globals are copied, which can mess up logging, threads don't survive fork(), etc.. The end

[issue14976] queue.Queue() is not reentrant, so signals and GC can cause deadlocks

2017-04-16 Thread Itamar Turner-Trauring
Itamar Turner-Trauring added the comment: This bug was closed on the basis that signals + threads don't interact well. Which is a good point. Unfortunately this bug can happen in cases that have nothing to do with signals. If you look at the title and some of the comments it also happens

[issue14976] queue.Queue() is not reentrant, so signals and GC can cause deadlocks

2014-02-17 Thread Itamar Turner-Trauring
Itamar Turner-Trauring added the comment: This is not specifically a signal issue; it can happen with garbage collection as well if you have a Queue.put that runs in __del__ or a weakref callback function. This can happen in real code. In my case, a thread that reads log messages from

[issue19206] Support disabling file I/O when doing traceback formatting

2013-10-09 Thread Itamar Turner-Trauring
New submission from Itamar Turner-Trauring: In certain situations it is best to avoid doing file I/O. For example, a program that runs in an event loop may wish to avoid any potentially blocking operations; reading from a file usually is fast, but can sometimes take arbitrary long. Another