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 tim.peters
Recipients Kevin Shweh, SnoopJeDi, bjs, eryksun, pitrou, serhiy.storchaka, tim.peters, vstinner
Date 2022-02-13.18:41:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1644777675.0.0.700563733952.issue46726@roundup.psfhosted.org>
In-reply-to
Content
>> is there a bulletproof way to guarantee that `self._stop()` gets 
>> called if the acquire_and_release() succeeds? 

> I don't think it's critical.

Agreed! Anything at the Python level that cares whether the thread is still alive will call _wait_for_tstate_lock() again, and get another chance each time to notice that the tstate lock has been freed.

Instead of:

        try:
            if lock.acquire_and_release(block, timeout):
                self._stop
        except:
            if not lock.locked():
                self._stop()

I'd prefer:

        try:
            lock.acquire_and_release(block, timeout)
        finally:
            if not lock.locked():
                self._stop()

Because, at the Python level, whether acquire_and_release() succeeded at its task depends entirely on whether the lock is free afterward. That's what we're _really_ looking for, and is so on all possible platforms.
History
Date User Action Args
2022-02-13 18:41:15tim.peterssetrecipients: + tim.peters, pitrou, vstinner, serhiy.storchaka, eryksun, Kevin Shweh, bjs, SnoopJeDi
2022-02-13 18:41:15tim.peterssetmessageid: <1644777675.0.0.700563733952.issue46726@roundup.psfhosted.org>
2022-02-13 18:41:14tim.peterslinkissue46726 messages
2022-02-13 18:41:14tim.peterscreate