Skip to content

gh-104341: Call _PyEval_ReleaseLock() with NULL When Finalizing the Current Thread #105109

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Jun 1, 2023
Merged

gh-104341: Call _PyEval_ReleaseLock() with NULL When Finalizing the Current Thread #105109

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
5206f3d
Call _PyEval_ReleaseLock() with NULL when finalizing the current thread.
ericsnowcurrently May 30, 2023
db6d7ac
Temporarily adjust tstate->_status.cleared during interpreter_clear().
ericsnowcurrently May 30, 2023
a374f48
Disable the broken asserts.
ericsnowcurrently May 30, 2023
432db0c
Add a note about the race in drop_gil().
ericsnowcurrently May 31, 2023
1280e0d
Fix a typo.
ericsnowcurrently May 31, 2023
cc1f2fe
Clarify a comment.
ericsnowcurrently May 31, 2023
b64b299
minor comment typo fix.
gpshead Jun 1, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Disable the broken asserts.
  • Loading branch information
@ericsnowcurrently
ericsnowcurrently committed May 30, 2023
commit a374f48ea809f5c279cdd3e154dbf9307417c202
4 changes: 2 additions & 2 deletions Python/ceval_gil.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -280,7 +280,7 @@ drop_gil(struct _ceval_state *ceval, PyThreadState *tstate)
{
/* We shouldn't be using a thread state that isn't viable any more. */
Copy link
Member

@pitrou pitrou May 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is cryptic here. It doesn't say why it's here nor in which situation the "non-viable thread state" occurs.

Copy link
Member Author

@ericsnowcurrently ericsnowcurrently May 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've clarified the comment.

// XXX It may be more correct to check tstate->_status.finalizing.
assert(tstate == NULL || !tstate->_status.cleared);
// XXX assert(tstate == NULL || !tstate->_status.cleared);

struct _gil_runtime_state *gil = ceval->gil;
if (!_Py_atomic_load_relaxed(&gil->locked)) {
Expand Down Expand Up @@ -356,7 +356,7 @@ take_gil(PyThreadState *tstate)
assert(tstate != NULL);
/* We shouldn't be using a thread state that isn't viable any more. */
// XXX It may be more correct to check tstate->_status.finalizing.
assert(!tstate->_status.cleared);
// XXX assert(!tstate->_status.cleared);

if (tstate_must_exit(tstate)) {
/* bpo-39877: If Py_Finalize() has been called and tstate is not the
Expand Down