Changes by Tomaž Šolc :
--
nosy: -avian
___
Python tracker
<http://bugs.python.org/issue6721>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Tomaž Šolc added the comment:
> We can't do that, it would break existing code.
I would argue that such code is already broken.
> What do you mean by helper threads?
multiprocessing uses threads behind the scenes to handle queue traffic and such
for individual forked proc
Tomaž Šolc added the comment:
Except for multiprocessing, does anyone know of any other module in the
standard library that uses fork() and threads at the same time? After some
grepping through the source I couldn't find any other cases.
I'm still in favor of just deprecating using
Tomaž Šolc added the comment:
> You mean a runtime warning? That would be ugly and clumsy.
> A warning is probably a good idea, but it should be added somewhere in
os.fork() and threading documentation.
I was thinking about a run time warning that is emitted if you call os.fork()
Tomaž Šolc added the comment:
The way I see it is that Charles-François' patch trades a possibility of a
deadlock for a possibility of a child process running with inconsistent states
due to forcibly reinitialized locks.
Personally, I would rather have an occasional deadlock th
Changes by Tomaž Šolc :
--
nosy: +avian
___
Python tracker
<http://bugs.python.org/issue6721>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Tomaž Šolc added the comment:
I am pretty sure this is another instance of issue 6721.
multiprocessing is forking a new process and if that happens while the other
thread is holding the lock for stdout, the process will deadlock because the
lock state is replicated in the subprocess while
