Andrey Vlasovskikh added the comment:
> Would it be possible to modify the default implementation of sys.excepthook
> to have a different output when it's not called from the main thread? Mimick
> the current traceback from threads.
I agree it's a good idea to mimic what `_thr
Andrey Vlasovskikh added the comment:
I've added a PR with a patch I developed during the EuroPython 2018 sprint.
I've fixed this issue in a way that is more or less consistent with how
'_thread' threads interact with sys.excepthook, but I haven't added the log
line they print to sys.stderr
Change by Andrey Vlasovskikh :
--
keywords: +patch
pull_requests: +8116
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue1
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
Changes by Andrey Vlasovskikh andrey.vlasovsk...@gmail.com:
--
nosy: +vlasovskikh
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9205
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
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 long
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
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:
http://stackoverflow.com/questions/1408356/keyboard
11 matches
Mail list logo