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 arekm
Recipients BTaskaya, arekm, gaborjbernat, miss-islington, pablogsal, vstinner
Date 2020-03-16.10:43:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1584355395.72.0.69819004176.issue39360@roundup.psfhosted.org>
In-reply-to
Content
This one is also needed on 3.8 to get it not hang with 1) test case.

So 3.8 branch + 9ad58acbe8b90b4d0f2d2e139e38bb5aa32b7fb6 + 4d96b4635aeff1b8ad41d41422ce808ce0b971c8 is working for me.

commit 4d96b4635aeff1b8ad41d41422ce808ce0b971c8
Author: Victor Stinner <vstinner@python.org>
Date:   Sat Feb 1 02:30:25 2020 +0100

    bpo-39511: PyThreadState_Clear() calls on_delete (GH-18296)

    PyThreadState.on_delete is a callback used to notify Python when a
    thread completes. _thread._set_sentinel() function creates a lock
    which is released when the thread completes. It sets on_delete
    callback to the internal release_sentinel() function. This lock is
    known as Threading._tstate_lock in the threading module.

    The release_sentinel() function uses the Python C API. The problem is
    that on_delete is called late in the Python finalization, when the C
    API is no longer fully working.

    The PyThreadState_Clear() function now calls the
    PyThreadState.on_delete callback. Previously, that happened in
    PyThreadState_Delete().

    The release_sentinel() function is now called when the C API is still
    fully working.
History
Date User Action Args
2020-03-16 10:43:15arekmsetrecipients: + arekm, vstinner, pablogsal, miss-islington, gaborjbernat, BTaskaya
2020-03-16 10:43:15arekmsetmessageid: <1584355395.72.0.69819004176.issue39360@roundup.psfhosted.org>
2020-03-16 10:43:15arekmlinkissue39360 messages
2020-03-16 10:43:15arekmcreate