[issue9573] importing a module that executes fork() raises RuntimeError

Nick Coghlan added the comment: Fixed for 3.2 in r86928. The fix has not been backported to 3.1, since it depends on the fix for issue 7242 (r78527) which was itself never backported to 3.1 after being forward ported to the py3k branch as part of a bulk merge (r83318) Backporting to 2.7 woul

[issue9573] importing a module that executes fork() raises RuntimeError

Changes by Éric Araujo : -- assignee: -> ncoghlan versions: +Python 3.1, Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailin

[issue9573] importing a module that executes fork() raises RuntimeError

Nick Coghlan added the comment: On further further reflection - I'm back to thinking my patch is correct. With the way fork is now implemented, the forking thread *always* holds the import lock, so the assumption in my patch regarding the meaning of the nesting level is correct. It could use

[issue9573] importing a module that executes fork() raises RuntimeError

Alex Roitman added the comment: Will starting a thread while in import also be disallowed? If so, issue 7242 will also become moot... -- ___ Python tracker ___

[issue9573] importing a module that executes fork() raises RuntimeError

Gregory P. Smith added the comment: Agreed on the explicit exception and documentation. :) -- ___ Python tracker ___ ___ Python-bugs-l

[issue9573] importing a module that executes fork() raises RuntimeError

Alex Roitman added the comment: I already worked around this for my use case. For the future, it would be nice if fork() raised an exception if called during the import, and if the documentation mentioned that forking while in import is not allowed. -- __

[issue9573] importing a module that executes fork() raises RuntimeError

Alex Roitman added the comment: gregory.p.smith: This is my use case: we had the following situation with the test scripts at work. Each script is required to import TestApi module in order to run the tests. That module in turn imported the module that forks, and in the parent waits for the

[issue9573] importing a module that executes fork() raises RuntimeError

Nick Coghlan added the comment: It turns out my proposed patch is incorrect anyway - it will do the wrong thing if a thread *other* than the one doing the fork is in the middle of a nested import at the time the fork occurs. With issue 7242 establishing that the current thread ID may not surv

[issue9573] importing a module that executes fork() raises RuntimeError

Gregory P. Smith added the comment: Are there any applications out there that actually rely on forking during import? (someone discovered this bug... i'd like to know why. i think its a disgusting thing to do but never explicitly disallowed it in the past) -- __

[issue9573] importing a module that executes fork() raises RuntimeError

Barry A. Warsaw added the comment: I think it's too late to try to get this into 2.6.6. rc2's already been released, I don't expect/want an rc3, and I'm not comfortable changing this at this point. Unless you can convince me it's absolutely critical, I won't approve this for 2.6.6. ---

[issue9573] importing a module that executes fork() raises RuntimeError

Nick Coghlan added the comment: Test script attached that demonstrates the underlying problem directly via imp.lock_held() (this could easily form the basis of a unit test) -- Added file: http://bugs.python.org/file18552/fork_on_import.py ___ Python

[issue9573] importing a module that executes fork() raises RuntimeError

Nick Coghlan added the comment: Minimal patch attached (no niceties like NEWS or unit tests included yet) -- keywords: +patch Added file: http://bugs.python.org/file18551/issue9573_fork_on_import.diff ___ Python tracker

[issue9573] importing a module that executes fork() raises RuntimeError

Nick Coghlan added the comment: One slight tweak to that suggested change - the lock reinitialisation needs to acquire the new lock in the first branch. -- ___ Python tracker __

[issue9573] importing a module that executes fork() raises RuntimeError

Nick Coghlan added the comment: Added Greg to nosy list as the one that fixed issue 7242 with the current _PyImport_ReInitLock semantics. Also kicking over to Barry regarding implications for 2.6.6 (this is a regression from 2.6.4 due to the resolution of 7242). 7242 was about forking from a

[issue9573] importing a module that executes fork() raises RuntimeError

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue9573] importing a module that executes fork() raises RuntimeError

Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue9573] importing a module that executes fork() raises RuntimeError

Changes by Alexander Belopolsky : -- Removed message: http://bugs.python.org/msg113654 ___ Python tracker ___ ___ Python-bugs-list mail

[issue9573] importing a module that executes fork() raises RuntimeError

Changes by Alexander Belopolsky : -- nosy: -belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue9573] importing a module that executes fork() raises RuntimeError

Alex Roitman added the comment: 1. If fork should not be called during import, it could raise an exception when invoked from import. But it does not. Is that a bug then? BTW, fork during import worked with python 2.4 just fine. 2. The whole issue7242 was devoted to work out import locks du