Changes by Brian Curtin br...@python.org:
--
nosy: -brian.curtin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
___
___
Python-bugs-list
Changes by Steven Myint c...@stevenmyint.com:
--
nosy: +myint
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
___
___
Python-bugs-list mailing
Markus Unterwaditzer added the comment:
Can this issue or #9205 be reopened as this particular instance of the problem
doesn't seem to be resolved? I still seem to need the workaround from
http://stackoverflow.com/a/1408476
--
nosy: +untitaker
___
Changes by Ned Deily n...@acm.org:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
___
___
Python-bugs-list mailing list
Changes by Martin Dengler mar...@martindengler.com:
--
nosy: +mdengler
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
___
___
Python-bugs-list
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
Closing, as Andrey Vlasovskikh has agreed that this is a duplicate of #9205.
--
nosy: +vinay.sajip
resolution: - duplicate
status: open - closed
___
Python tracker rep...@bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
Note that #9205 fixed concurrent.futures, but not multiprocessing.Pool which is
a different kettle of fish.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
Changes by Gökçen Eraslan gok...@pardus.org.tr:
--
nosy: +Gökçen.Eraslan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
___
___
Changes by Greg Brockman g...@mit.edu:
--
nosy: +gdb
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
___
___
Python-bugs-list mailing list
Andrey Vlasovskikh andrey.vlasovsk...@gmail.com added the comment:
On closer look your patch is also ignoring SystemExit. I think it's
beneficial to honor SystemExit, so a user could use this as a means to
replace the current process with a new one.
Yes, SystemExit should cancel all the
Ask Solem a...@opera.com added the comment:
On closer look your patch is also ignoring SystemExit. I think it's beneficial
to honor SystemExit, so a user could use this as a means to replace the current
process with a new one.
If we keep that behavior, the real problem here is that the
result
Jesse Noller jnol...@gmail.com added the comment:
If we keep that behavior, the real problem here is that the
result handler hangs if the process that reserved a job is gone, which is
going to be handled
by #9205. Should we mark it as a duplicate?
I would tend to agree with your
Changes by Albert Strasheim full...@gmail.com:
--
nosy: +Albert.Strasheim
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
___
___
Albert Strasheim full...@gmail.com added the comment:
Any chance of getting this patch applied? Thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
___
Changes by Brian Curtin cur...@acm.org:
--
nosy: +asksol
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
___
___
Python-bugs-list mailing list
Ask Solem a...@opera.com added the comment:
This is related to our discussions at #9205 as well
(http://bugs.python.org/issue9205), as the final patch there will also fix this
issue.
--
___
Python tracker rep...@bugs.python.org
Andrey Vlasovskikh andrey.vlasovsk...@gmail.com added the comment:
Despite of several workarounds available on the Web, the problem persists.
Almost any exception that is rised in `worker` function while putting or
getting tasks from queues result in Pool hang up. Currently, `worker` is only
Changes by Andrey Vlasovskikh andrey.vlasovsk...@gmail.com:
Removed file: http://bugs.python.org/file16743/test_pool_keyboardinterrupt.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
___
Andrey Vlasovskikh andrey.vlasovsk...@gmail.com added the comment:
Here is a patch that fixes this problem. Basically, it catches all the
BaseExceptions that could happen during: a) getting a task from the `inqueue`,
b) calling a user function, c) putting a task into the `outqueue`. The
Changes by Brian Curtin cur...@acm.org:
--
nosy: +jnoller
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
___
___
Python-bugs-list mailing list
New submission from Andrey Vlasovskikh andrey.vlasovsk...@gmail.com:
multiprocessing.Pool methods map, imap, etc. are said to be able to normally
handle exceptions. But it seems that it is true only for synchronous exceptions
inside their first func arguments.
When (typically during a
Brian Curtin cur...@acm.org added the comment:
Do you have a test case which can reproduce the issue?
--
nosy: +brian.curtin
stage: - test needed
type: crash - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
Andrey Vlasovskikh andrey.vlasovsk...@gmail.com added the comment:
Yes, here is my test case.
--
Added file: http://bugs.python.org/file16743/test_pool_keyboardinterrupt.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
Brian Curtin cur...@acm.org added the comment:
You might want to take a look here:
http://jessenoller.com/2009/01/08/multiprocessingpool-and-keyboardinterrupt/
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8296
Andrey Vlasovskikh andrey.vlasovsk...@gmail.com added the comment:
Yes, I've come up with the same solution by myself, but it cannot cover all the
cases of the bug. It works only for cases when ^C is hit during a call to the
users' function:
25 matches
Mail list logo
