This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients belopolsky, brett.cannon, christian.heimes, grahamd, gvanrossum, ncoghlan, neologix, pitrou, vstinner
Date 2011-12-29.13:45:48
SpamBayes Score 1.59352e-07
Marked as misclassified No
Message-id <>
In-reply-to <>
IIUC, the deadlock avoidance code just checks that acquiring a
per-module lock won't create a cycle.
However, I think there's a race, because the cycle detection and the
lock acquisition is not atomic.

For example, let's say we have a thread exactly here in in
        PyThread_acquire_lock(lock->lock, 1);
        /* thread inside PyEval_RestoreThread(), waiting for the GIL */
    assert(lock->level == 0);
    lock->tstate = tstate;

It owns the lock, but hasn't yet updated the lock's owner
(lock->tstate), so another thread calling detect_circularity() will
think that this lock is available, and will proceed, which can
eventually lead to a deadlock.

Also, I think that locks will use POSIX semaphores on systems that
support only a limited number of them (such as FreeBSD 7), and this
might fail in case of nested imports (the infamous ENFILE). I'd have
to double check this, though.
Date User Action Args
2011-12-29 13:45:49neologixsetrecipients: + neologix, gvanrossum, brett.cannon, ncoghlan, belopolsky, pitrou, vstinner, christian.heimes, grahamd
2011-12-29 13:45:48neologixlinkissue9260 messages
2011-12-29 13:45:48neologixcreate