Skip to content

bpo-39995: CLN remove some locks in ProcessPoolExecutor #19788

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.

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

tomMoral
Copy link
Contributor

@tomMoral tomMoral commented Apr 29, 2020

Follow-up of #19760 to try to remove some locks.

Actually, the only one that matters in term of perf is probably the one in Lib/concurrent/futures/process.py#L171 which would be concurrent with the job submission. It can be removed because this lock is here to protect against concurrent call to close which is only called in the same thread as clear so the protection is unecesary.

We can also remove the one in SafeQueue because the queue is closed (and thus the queue feeder thread join) before we call thread_wakeup.close. But this is not really changing the perf so maybe we could leave it. Let me know what you prefer.

Finally, the call to wakeup in _python_exit was indeed not protected and this could lead to the same race condition. I added a lock here to make sure we avoid this. (A bit more complicated than expected as the _python_exit was leaking in the workers).

I launched 50times the tests with @vstinner patch and did not observed the failure so I think this is working.

https://bugs.python.org/issue39995

@@ -658,7 +660,8 @@ def _start_executor_manager_thread(self):
self._executor_manager_thread = _ExecutorManagerThread(self)
self._executor_manager_thread.start()
_threads_wakeups[self._executor_manager_thread] = \
self._executor_manager_thread_wakeup
(self._shutdown_lock,
self._executor_manager_thread_wakeup)
Copy link
Member

Choose a reason for hiding this comment

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

Oh, I never tried a weakref.WeakKeyDictionary() where the value a tuple of two objects.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you think this could be a problem? I did not even thing about this..

Copy link
Member

Choose a reason for hiding this comment

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

As long as they key isn't a temporary object this is fine.

@vstinner
Copy link
Member

@tomMoral @pitrou: What's the status of this PR? Is it worth it?

I would like to close https://bugs.python.org/issue39995 since the initial issue has been fixed :-)

@tomMoral
Copy link
Contributor Author

I would this PR improves a bit the state with the protection of the at exit call _python_exit and with the clean up for fork context.

@iritkatriel
Copy link
Member

https://bugs.python.org/issue39995 is closed. What is the status of this PR?

@github-actions
Copy link

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale Stale PR or inactive for long period of time. label Jul 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting review stale Stale PR or inactive for long period of time.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants