New submission from Reid Kleckner <r...@mit.edu>: This bug is similar to the importlock deadlock, and it's really part of a larger problem that you should release all locks before you fork. However, we can fix this in the threading module directly by freeing and resetting the locks on the main thread after a fork.
I've attached a test case that inserts calls to sleep at the right places to make the following occur: - Main thread spawns a worker thread. - Main thread joins worker thread. - To join, the main thread acquires the lock on the condition variable (worker.__block.acquire()). == switch to worker == - Worker thread forks. == switch to child process == - Worker thread, which is now the only thread in the process, returns. - __bootstrap_inner calls self.__stop() to notify any other threads waiting for it that it returned. - __stop() tries to acquire self.__block, which has been left in an acquired state, so the child process hangs here. == switch to worker in parent process == - Worker thread calls os.waitpid(), which hangs, since the child never returns. So there's the deadlock. I think I should be able to fix it just by resetting the condition variable lock and any other locks hanging off the only thread left standing after the fork. ---------- components: Library (Lib) files: forkjoindeadlock.py messages: 91265 nosy: rnk severity: normal status: open title: joining a child that forks can deadlock in the forked child process versions: Python 2.6 Added file: http://bugs.python.org/file14647/forkjoindeadlock.py _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6643> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
