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.goldschm...@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 > -- https://mail.python.org/mailman/listinfo/python-list
