Lock acquisition by the same thread - deadlock protection

[Souvik Dutta]

Soorrrryyy it was not meant to you

On Tue, 10 Mar, 2020, 8:00 am Souvik Dutta, <souvik.viksou at gmail.com> wrote:

> This should be what you need.
> https://python-reference.readthedocs.io/en/latest/docs/functions/super.html
>
> On Tue, 10 Mar, 2020, 7:02 am Yonatan Goldschmidt, <
> yon.goldschmidt at gmail.com> wrote:
>
>> I recently debugged a program hang, eventually finding out it's a
>> deadlock of a single thread,
>> resulting from my usage of 2 libraries. One of them - call it library A -
>> is reentrant & runs code in
>> GC finalizers, while the other - library B - is not reentrant at all.
>> Library B held one of its `threading.Lock` locks, and during this period,
>> GC was invoked, running
>> finalizers of library A which call back into library B, now attempting to
>> take the lock again,
>> locking the thread forever.
>>
>> Considering how relatively common this scenario might be (Python, by
>> design, can preempt any user code
>> to run some other user code, due to GC finalizers), I was surprised
>> Python code is not protected
>> from this simple type of deadlock. It makes sense that while
>> `threading.RLock` allows for recursive
>> locking, `threading.Lock` will prevent it - raising an exception if you
>> attempt it.
>>
>> I might be missing something, but why isn't it the status? Why taking a
>> `threading.Lock` twice from
>> the same thread just hangs, instead of raising a friendly exception?
>> I ran a quick search in bpo but found nothing about this topic. I also
>> tried to
>> search this mailing list but couldn't find how to, so I grepped a few
>> random archives
>> but found nothing about it.
>>
>> Would be happy if anyone could shed some light on it...
>>
>> Thanks,
>> Yonatan
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>