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

Nick Coghlan report at bugs.python.org
Tue Aug 17 04:08:44 CEST 2010


Nick Coghlan <ncoghlan at gmail.com> 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 *thread*. This is about forking as a side effect of import, which, just like spawning a thread as a side effect of import, can easily cause issues.

The RuntimeError noted by the OP isn't thrown by the fork() call - it is thrown at the end of the import when control is returned to the main module. Completely reinitialising the lock without accounting for the current depth of nesting is incorrect. Instead, I believe ReInitLock should look more like:

    if (import_lock != NULL)
        import_lock = PyThread_allocate_lock();
    if (import_lock_level > 1) {
        /* Forked as a side effect of import */
        long me = PyThread_get_thread_ident();
        import_lock_thread = me;
        import_lock_level--;
    } else {
        import_lock_thread = -1;
        import_lock_level = 0;
    }

(I haven't tested that yet, but will soon)

----------
assignee:  -> barry
nosy: +barry, gregory.p.smith
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9573>
_______________________________________


More information about the Python-bugs-list mailing list