Sergei Zobov added the comment:
So, should I just close this issue in case we've decided it's not a big problem?
--
___
Python tracker
<https://bugs.python.org/issue35
Sergei Zobov added the comment:
Thanks for answer, Antoine!
I see what you mean, but I'm not sure that it's so extreme corner case. We are
speaking about Python and it's easy to create an put an unpickable object into
queue.
I apologize for the persistence, but I just want make this case
Sergei Zobov added the comment:
Yes, I've missed that the daemonic thread won't work if the parent process
finished. The similarities between multiprocessing and threading modules are
confusing a bit.
Anyway, could I make a patch to fix the problem with the silently ignored
exception
Change by Sergei Zobov :
--
nosy: +pitrou
___
Python tracker
<https://bugs.python.org/issue35242>
___
___
Python-bugs-list mailing list
Unsubscribe:
Sergei Zobov added the comment:
I've decided to make the test more clean, so I added `time.sleep` and now we
can be sure that here is enough time for queue's underlying process to
synchronize all variables:
https://github.com/szobov/cpython/compare/master...regression-test-on-multiprocessing
Change by Sergei Zobov :
--
components: +Library (Lib)
___
Python tracker
<https://bugs.python.org/issue35242>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Sergei Zobov :
In case if the process target function put something unpickable in the
`multiprocessing.Queue` and finish before `ForkingPickler`'s exception is
handled we get two weird situations:
* Internal queue semaphore stay acquired and never will be released, so we
