On 16-mei-2006, at 23:20, Martin v. Löwis wrote:
Nick Coghlan wrote:Broadening the ifdef to cover all posix systems rather than just AIX might be the right thing to do.As I said: I doubt it is the right thing to do. Instead, the lock should get released in the child process if it is held at the point of the fork. I agree that we should find a repeatable test case first. Contributions are welcome.
From what I understand the problem is that when a thread other than the thread calling fork is holding the import lock the child process ends up with an import lock that is locked by a no longer existing thread.
The attached script reproduces the problem for me. This creates a thread to imports a module and a thread that forks. Run 'forkimport.py' to demonstrate the problem, if you set 'gHang' at the start of the script to 0 the child process doesn't perform an import and terminates normally.
Wouldn't this specific problem be fixed if os.fork were to acquire the import lock before calling fork(2)?
Ronald
forklock.tgz
Description: Binary data
Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-devUnsubscribe: http://mail.python.org/mailman/options/python-dev/ ronaldoussoren%40mac.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
