Remove minimum in Fiber::ExecutionContext::Parallel#15946
Merged
straight-shoota merged 6 commits intocrystal-lang:masterfrom Jul 23, 2025
Merged
Conversation
ysbaddaden
commented
Jul 1, 2025
ysbaddaden
added a commit
to ysbaddaden/crystal
that referenced
this pull request
Jul 1, 2025
…-lang#15946) The context should be in control of the overall parallelism of the context. In light of the incoming thread pool it makes more sense for threads to be returned to the pool, so they can increase the parallelism of contexts that need it, without starting more and more system threads.
The context should be in control of the overall parallelism of the context. In light of the incoming thread pool it makes more sense for threads to be returned to the pool, so they can increase the parallelism of contexts that need it, without starting more and more system threads.
ysbaddaden
force-pushed
the
rework/remove-minimum-range-of-parallel-execution-context
branch
from
494e8a4 to
8db16d1
Compare
Collaborator
Author
|
I added the deprecated constructors back. Since the feature is experimental they ignore the minimum, and the constructors themselves shall be removed in the next release. |
…imum-range-of-parallel-execution-context
straight-shoota
approved these changes
Jul 21, 2025
ysbaddaden
deleted the
rework/remove-minimum-range-of-parallel-execution-context
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Having a minimal number of threads felt normal, but starting a parallel context with a minimum starts that number of schedulers and threads, but there's nothing to do, so the schedulers park the threads almost immediately, and even before we could spawn a fiber into the context.
The same happens when the context has no fibers to run: the schedulers park, and the parallelism returns to zero.
The actual parallelism will always reach zero instead of the configured minimum.
In practice, the range is
0..maxnotmin..max: every parallel context starts at zero, increases to one when a first fiber is pushed, then the context will decide to increase the parallelism (assign more threads to run the schedulers) and decrease the parallelism based on the context current needs, up to the maximum parallelism, that may or may not be reached.NOTE: the range is actually
0on creation, then1..maxbecause we keep a thread to run the context's event loop (that might change in the future, if the context knows it has zero fibers).follow up to #15936