Author rnk
Recipients rnk
Date 2009-08-04.18:56:48
SpamBayes Score 7.51299e-09
Marked as misclassified No
Message-id <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2009-08-04 18:56:49rnksetrecipients: + rnk
2009-08-04 18:56:49rnksetmessageid: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
2009-08-04 18:56:48rnklinkissue6643 messages
2009-08-04 18:56:48rnkcreate