This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sbt
Recipients kristjan.jonsson, neologix, pitrou, sbt
Date 2013-05-13.17:32:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1368466355.2.0.615091104071.issue17969@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.
History
Date User Action Args
2013-05-13 17:32:35sbtsetrecipients: + sbt, pitrou, kristjan.jonsson, neologix
2013-05-13 17:32:35sbtsetmessageid: <1368466355.2.0.615091104071.issue17969@psf.upfronthosting.co.za>
2013-05-13 17:32:35sbtlinkissue17969 messages
2013-05-13 17:32:35sbtcreate