Skip to content

Conversation

@aisk
Copy link
Contributor

@aisk aisk commented Oct 13, 2025

The idea is simple and naive: just add a PyMutex to the PyInterpreterState for the executor_list under the nogil build, and lock or unlock the mutex in all functions that operate on the executor_list.

Since I'm not very familiar with the related code, there might be a better way to do this, so any feedback would be appreciated!

@bedevere-app bedevere-app bot mentioned this pull request Oct 13, 2025
7 tasks
@aisk aisk added the skip news label Oct 13, 2025
@aisk aisk changed the title gh-133171: Add lock on operations to executor_list gh-133171: Make the executor_list thread-safe Oct 13, 2025
Copy link
Member

@ZeroIntensity ZeroIntensity left a comment

Choose a reason for hiding this comment

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

I'm not entirely sure that a mutex is safe here, because we're locking code paths that call Py_DECREF. @Fidget-Spinner, can these paths escape?

@Fidget-Spinner
Copy link
Member

In theory, Py_DECREF(executor) could clear the (future) constants pool that we plan to add, which would hold arbitrary constant objects, which can escape.

@corona10
Copy link
Member

corona10 commented Oct 15, 2025

I am not sure if making executor_list operations thread-safe at this point is good idea.
There is no way to verify that we make the thread-safe until we actually integrate the whole pipeline. I do believe that we have to do more things before we start to work on this task.

@Fidget-Spinner
Copy link
Member

@corona10 we need the executor list to be thread safe for it to work with the plan here #133171 (comment).

@aisk could you resume the PR please?

void
_Py_Executors_InvalidateAll(PyInterpreterState *interp, int is_invalidation)
{
EXECUTOR_LIST_LOCK(interp);
Copy link
Member

Choose a reason for hiding this comment

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

This should be a stop the world event.

}
/* Clearing an executor can deallocate others, so we need to make a list of
* executors to invalidate first */
EXECUTOR_LIST_LOCK(interp);
Copy link
Member

Choose a reason for hiding this comment

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

This is fine. nice.!

@corona10
Copy link
Member

corona10 commented Nov 7, 2025

I will try to re review this PR in this weekend.

@corona10
Copy link
Member

corona10 commented Nov 7, 2025

Share the DM context between @Fidget-Spinner and I.

Before merging this PR, we should investigate the current blocker #133171 (comment) to verify this PR in practice.

@aisk
Copy link
Contributor Author

aisk commented Nov 9, 2025

Hi @ZeroIntensity @corona10 @Fidget-Spinner , thanks for the review and feedback. I'll bring this PR up to date while waiting for #133171 (comment) to be resolved.

Comment on lines +303 to +307
/* Release the lock before calling _Py_ClearExecutorDeletionList
* to avoid deadlock, since it also tries to acquire the same lock */
EXECUTOR_LIST_UNLOCK(interp);
_Py_ClearExecutorDeletionList(interp);
EXECUTOR_LIST_LOCK(interp);
Copy link
Member

Choose a reason for hiding this comment

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

Do we still need this?

@Fidget-Spinner
Copy link
Member

Sorry, now that I think about it, locking isn't the right choice here. We should instead move the executor list to tstate.

Really sorry for taking up your time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants