Charles-François Natali <[email protected]> added the comment:
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
acquire_import_lock():
PyThread_acquire_lock(lock->lock, 1);
/* thread inside PyEval_RestoreThread(), waiting for the GIL */
PyEval_RestoreThread(saved);
lock->waiters--;
}
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.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue9260>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
