Author Albert.Zeyer
Recipients Albert.Zeyer, neologix, pitrou, r.david.murray
Date 2013-02-26.13:40:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1361886017.26.0.261445254925.issue17263@psf.upfronthosting.co.za>
In-reply-to
Content
> > Wouldn't it be better to expose and re-use the HEAD_LOCK and HEAD_UNLOCK
> > macros from pystate.c?

> I don't like holding locks before calling "alien" code, it's a recipe
> for deadlocks: for example, if another thread-local object was
> deallocated as part of the deallocation chain, we would call back into
> local_clear(), and deadlock.

Ah, yes. Right now, the head-lock is acquired while the GIL is held. So while the head-lock is held, we must not unlock the GIL. So this wouldn't work.

Btw., I think it also does happen already. While playing around with this test case, I sometimes encountered a deadlock at quit. I was thinking that it was the result of some badly written memory.

But I just saw this code (PyInterpreterState_Clear):

    HEAD_LOCK();
    for (p = interp->tstate_head; p != NULL; p = p->next)
        PyThreadState_Clear(p);
    HEAD_UNLOCK();

So, if something inside PyThreadState_Clear unlocks the GIL and some other thread acquires the GIL and then tries to HEAD_LOCK (for example, at thread exit), you have a classic deadlock.

A solution would be: Only acquire the head-mutex while the GIL is not held. Then, after you held the head-mutex, also acquire the GIL.
History
Date User Action Args
2013-02-26 13:40:17Albert.Zeyersetrecipients: + Albert.Zeyer, pitrou, r.david.murray, neologix
2013-02-26 13:40:17Albert.Zeyersetmessageid: <1361886017.26.0.261445254925.issue17263@psf.upfronthosting.co.za>
2013-02-26 13:40:17Albert.Zeyerlinkissue17263 messages
2013-02-26 13:40:16Albert.Zeyercreate