Soorrrryyy it was not meant to you On Tue, 10 Mar, 2020, 8:00 am Souvik Dutta, <souvik.vik...@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.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
