Skip to content

bpo-44733: Add maxtasksperchild to ProcessPoolExecutor #27373

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

Merged
merged 7 commits into from
Nov 20, 2021

Conversation

loganasherjones
Copy link
Contributor

@loganasherjones loganasherjones commented Jul 26, 2021

Copy link
Contributor

@cool-RR cool-RR left a comment

Choose a reason for hiding this comment

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

Good work Logan! I didn't expect the documentation to be already written. I gave one minor note, and I'll wait for someone who's experienced with this module to add a review. This is probably one of the most complex modules in the standard library, and there are many pitfalls to avoid.

@loganasherjones
Copy link
Contributor Author

@cool-RR thanks! I've never made a contribution like this so I wasn't sure if I should write docs or not.

And yeah, I was a bit worried about modifying this code because I know it's quite complex. I got all the tests to pass which I figured was a good start, but I'm a bit worried because it seems like worker processes were only originally designed to exit once a shutdown was initiated.

I'm exited for a review :)

@loganasherjones
Copy link
Contributor Author

I noticed the docs CI is failing, but the error message does not make any sense to me.

@cool-RR
Copy link
Contributor

cool-RR commented Jul 27, 2021

@loganasherjones
Confusing indeed. "default role used" might refer to the way you used backticks in your RST file. Look at how other similar files are written, I believe they use a different style.

@cool-RR
Copy link
Contributor

cool-RR commented Aug 7, 2021

@pitrou do you have time to look at Logan's PR?

Copy link
Member

@pitrou pitrou left a comment

Choose a reason for hiding this comment

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

Thank you for posting this PR. Here are some comments.

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@loganasherjones loganasherjones force-pushed the issue-44733 branch 2 times, most recently from 0b59566 to ca79201 Compare August 20, 2021 18:14
f2 = executor.submit(mul, 6, 7)
f3 = executor.submit(mul, 6, 7)
self.assertEqual(f2.result(), 42)
self.assertEqual(f3.result(), 42)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not assert that there weren't multiple PIDs up to this point?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can change around the order here and assert it on the 2nd result, but not the third.

Copy link
Contributor

Choose a reason for hiding this comment

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

That's good. But why isn't the third run guaranteed to have the same PID?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The problem is it's a race condition.

If I submit the third job, I have to check executor._processes before that worker gets the work item, finishes it and shuts down.

It could either result in an error doing self.assertEqual(len(exectuor._processes), 1) because the worker has already shut down. Even if that doesn't fail, there's no guarantee that the process hasn't already been replaced.

I could get around this by calling sleep_and_print but then it's just introducing a timing-dependent test and I figured we wouldn't want to do that.

Copy link
Contributor

Choose a reason for hiding this comment

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

That makes sense. Thank you.

@loganasherjones
Copy link
Contributor Author

@cool-RR think this is ready for me to ping the core devs again? (assuming these tests pass)

@cool-RR
Copy link
Contributor

cool-RR commented Aug 20, 2021

Yes, please do.

@loganasherjones
Copy link
Contributor Author

I have made the requested changes; please review again.

@bedevere-bot
Copy link

Thanks for making the requested changes!

@pitrou: please review the changes made to this pull request.

@bedevere-bot bedevere-bot requested a review from pitrou August 20, 2021 20:04
@cool-RR
Copy link
Contributor

cool-RR commented Sep 1, 2021

@pitrou ping.

@loganasherjones
Copy link
Contributor Author

I have made the requested changes; please review again.

@bedevere-bot
Copy link

Thanks for making the requested changes!

@pitrou: please review the changes made to this pull request.

@bedevere-bot bedevere-bot requested a review from pitrou September 15, 2021 00:25
@loganasherjones
Copy link
Contributor Author

I have made the requested changes; please review again.

Hi @pitrou so this last set of changes I think is probably the best we've come up with. Let me know what you think!

@bedevere-bot
Copy link

Thanks for making the requested changes!

@pitrou: please review the changes made to this pull request.

@bedevere-bot bedevere-bot requested a review from pitrou October 31, 2021 00:33
@loganasherjones
Copy link
Contributor Author

friendly ping @pitrou :)

Copy link
Member

@pitrou pitrou left a comment

Choose a reason for hiding this comment

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

Thanks @loganasherjones ! I pushed some small updates and merged upstream changes.

@pitrou pitrou added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Nov 20, 2021
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by @pitrou for commit e4cbc3a 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Nov 20, 2021
@cool-RR
Copy link
Contributor

cool-RR commented Nov 20, 2021

Woohoo!

@pitrou pitrou added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Nov 20, 2021
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by @pitrou for commit cfeefb8 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Nov 20, 2021
@pitrou
Copy link
Member

pitrou commented Nov 20, 2021

Ok, CI is green enough, I'll merge.

@pitrou pitrou merged commit fdc0e09 into python:main Nov 20, 2021
@loganasherjones loganasherjones deleted the issue-44733 branch November 22, 2021 00:40
remykarem pushed a commit to remykarem/cpython that referenced this pull request Dec 7, 2021
gpshead added a commit to gpshead/cpython that referenced this pull request Jan 24, 2022
…thonGH-27373)"

This reverts commit fdc0e09.

This implementation relies on a mechanism for spawning new children
dynamically rather than up front that leads to deadlocks due to mixing
of threads+fork.  See bpo-46464.
gpshead added a commit to gpshead/cpython that referenced this pull request Apr 16, 2022
…thonGH-27373)"

This reverts commit fdc0e09.

This implementation relies on a mechanism for spawning new children
dynamically rather than up front that leads to deadlocks due to mixing
of threads+fork.  See bpo-46464.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants