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 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 <>
> > 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):

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

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.
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: <>
2013-02-26 13:40:17Albert.Zeyerlinkissue17263 messages
2013-02-26 13:40:16Albert.Zeyercreate