Changes by Tomaž Šolc tomaz.s...@tablix.org:
--
nosy: -avian
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6721
___
___
Python-bugs-list mailing
Tomaž Šolc tomaz.s...@tablix.org 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
Tomaž Šolc tomaz.s...@tablix.org 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
Tomaž Šolc tomaz.s...@tablix.org 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
Tomaž Šolc tomaz.s...@tablix.org 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
Tomaž Šolc tomaz.s...@tablix.org 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
Changes by Tomaž Šolc tomaz.s...@tablix.org:
--
nosy: +avian
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6721
___
___
Python-bugs-list mailing
