Message189154
> We can consider two options then:
> 1) A multiprocessing specific fix. Removing this handle close gil
> release (which is superfluous, since these calls aren't blocking in any
> real sense) will certainly remove _this_ instance of the crash. An
> alternative is to make this worker thread non-daemon. That shouldn't
> be too hard and shouldn't have any other side effects.
Have you tried doing
p = Pool()
try:
...
finally:
p.close() # or perhaps p.terminate()
p.join()
Actually, making the worker thread non-daemonic is not so simple. This is because there is no way to interrupt a background thread which is blocked doing IO (unless you use multiplexing which is not possible with non-overlapped pipes).
One can try to unblock such background threads by reading/writing messages from/to the result/task pipe, but it not straightforward. |
|
Date |
User |
Action |
Args |
2013-05-13 17:32:35 | sbt | set | recipients:
+ sbt, pitrou, kristjan.jonsson, neologix |
2013-05-13 17:32:35 | sbt | set | messageid: <1368466355.2.0.615091104071.issue17969@psf.upfronthosting.co.za> |
2013-05-13 17:32:35 | sbt | link | issue17969 messages |
2013-05-13 17:32:35 | sbt | create | |
|