Richard Oudkerk added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17969> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com