-
Notifications
You must be signed in to change notification settings - Fork 506
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
Add full_blocking feature to thread pool #1175
base: main
Are you sure you want to change the base?
Conversation
Feel free to push directly to this PR. The documentation could be improved by matching the language to the rest of the rayon docs. I'm not 100% confident in the implementation of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! One small suggestion would be to make full_blocking
take a bool as an argument, so it can be toggled on or off. This seems to be more in line with the other builder methods.
I'll add that I tested my code using this branch and this does solve my own issue #957, which is essentially a variation of #592 🎉
Thanks for taking a look at the PR! The most similar function in the ThreadPoolBuilder is
Which sets a bool to true when called. I matched that function signature. |
That's fair. I would argue that |
@cuviper Are you interested in merging this? If not, can you close it? |
I need some time to think about the implications of this change, to make sure there aren't any big foot-guns here. But you're also helping solve a foot-gun, so that's going to be a balancing act. I might also bikeshed the name, but that's not a big deal. |
This PR adds an option
full_blocking
toThreadPoolBuilder
that affects the behavior of nested thread pools.When a job on a parent thread pool creates a job in a child thread pool and
full_blocking
is true, the parent job will block until the child job is completed. This is different from the default behavior where the parent thread is allowed to work on other jobs in the parent thread pool while the child job completes.This behavior is useful for avoiding deadlocks caused by work-stealing and is helpful for instrumentation based profiling in multi-threaded settings.
See for more details:
#1174