New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
threading module can deadlock after fork #39802
Comments
We have a Python HTTP server that, in the parent Anwyay, it very rarely causes deadlock in a spawned I believe I've tracked this down to the Just like the global interp. lock is overwritten in the This thread looks quite relevant: groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=38E6F2BA.E66CAC90%40ensim.com&rnum=5&prev=/groups%3Fq%3Dpython%2Bfork%2Bthreading%2Bmodule%2B%2Block%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26sa%3DN%26scoring%3Dd |
Logged In: YES See some more typical info about mixing forks and threads: This seems not to be Python-related, but platform-related. |
Logged In: YES True -- there are many platform specific issues on the However the _active_limbo_lock is entirely a Python issue (I After forking, python already resets the GIL, and it should |
It's not only the _active_limbo_lock. All global structures of the The safe_fork() function in the example is a replacement for os.fork() |
(or perhaps we should provide an API to hook into PyOS_AfterFork) |
Attached patch releases the _active_limbo_lock after a fork(). It is not |
A slightly better patch, with tests. |
Amaury - your latest patch doesn't seem to apply cleanly to trunk, it's |
Here is a third patch with latest trunk. |
I had to flip on ignore whitespace to patch: Worked. Unfortunately, test_threading is locking up during a make test. woot:python-trunk jesse$ ./python.exe Lib/test/regrtest.py -v At this point it hangs (OS/X 10.5 latest) |
Amaury, it looks like it's hanging in subprocess:
(Pdb) step
|
Here's the good news, with the patch applied to trunk, I'm not seeing |
Well I was a bit presumptuous that my thread+fork tests would pass on |
In general I suggest replacing the lock with a new lock, rather than I also suggest deleting _active and recreating it with only the current I don't understand how test_join_on_shutdown could succeed. The main I suspect test_join_in_forked_process should call os.waitpid(childpid) Ditto for test_join_in_forked_from_thread. |
Looking over some of the other platforms for thread_*.h, I'm sure |
A new patch:
Also, I hope the tests make more sense now. |
FWIW: the threading tests still hang for me with the latest patch. I'm |
I can confirm that this seems to clear up the test_multiprocessing hangs |
I agree. My attempt to describe the behaviour of fork+threads in a Just one more thing: looking at Module/posixmodule.c, os.fork1() calls |
I am leaving for the whole next week, so anyone, feel free to commit |
The existing fork-and-thread4.patch doesn't actually reset |
and a few more bugs. a new patch is attached. With this applied, test_threading, including the new deadlock tests, and Tested on x86 MacOS X 10.4 & x86 Ubuntu 8.04. Would someone please try this on other platforms? (The new threading test's use of subprocess with [sys.executable, '-c', |
I still don't like the _after_fork() implementation. Its O(n) where n Very wasteful when the fork() was done in the most common case of being Could os.fork() be extended to have an optional will_exec_or_die |
One of tests is hanging in 3.0. |
specifically, test_3_join_in_forked_from_thread hangs in py3k and is |
If you remove the print() call from joining_func(), does it stop |
This is also causing hangs in 2.5. |
it passes on release25-maint for me on linux. i don't see it hanging in (fwiw, that test you patched in 66003 should probably use readlines() |
Ok, with this patch the test passes under py3k. Apart from the trivial typo (_Thread__stopped -> _stopped), I had to I also added the ident fix I had already suggested in _after_fork(). If |
I feel like that patch sort of avoids the problem by changing the test. |
Benjamin, if you don't change the test, the deadlock problem is still |
On Thu, Sep 4, 2008 at 6:08 PM, Antoine Pitrou <report@bugs.python.org> wrote:
Ah! My apologies for the giant misunderstanding. |
Instead of os.write(), it is actually sufficient to sys.stdout.flush() |
Just checked that the latest patch works on Windows as well. |
forkthread2.patch looks good to me. to be consistent shouldn't we also |
Le samedi 06 septembre 2008 à 22:27 +0000, Gregory P. Smith a écrit :
Only the ident-resetting part needs to be backported, the rest is |
Committed in r66274, r66275. Thanks! |
I backported the last bit from r66275 to release25-maint in r66279. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: