Allow ThreadPool to run jobs in both modes, and improve scheduling
#1837
Conversation
This file contains 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
player-03
changed the title
ThreadPool to run jobs in both modesThreadPool to manage both job types, run jobs sooner
Since we're storing more and more in `JobData`, and the background thread only needs three bits of that data, I added those to `ThreadEvent` so we don't have to pass the full object. This may improve performance in HTML5 specifically, where passing a class instance incurs an overhead.
Now that thread pools can manage both types of job at once, we can't rely on `mode` to determine whether we're on a background thread. Honestly, I shouldn't have relied on it in the first place.
No need to set `__mainThread` based on `isWorker()` when `isWorker()` already gives the information we're after.
For single-threaded jobs, this means a pool can now handle multiple per frame. For multi-threaded jobs, this only slightly reduces the delay between jobs.
Forgot this when overriding the "send" functions.
player-03
force-pushed
the
multi_mode_ThreadPool
branch
from
68cc667 to
02d478d
Compare
It's a private variable, so all it really needs to do is mention the location it gets used.
Plus, alphabetize the variables. In 8.2.0, a single-threaded pool would report `currentThreads == 1` when running a job, meaning it counted the main thread. But in retrospect, this was both redundant (with `activeJobs`) and unexpected, so I'm counting it as a bug.
All the jobs in `__multiThreadedJobs` are already known to be running in multi-threaded mode. This is left over from when pools were locked to a single mode.
We still need to throw an error when `mode` is `MULTI_THREADED`, but this can now vary per job, so the check must happen during `run()`. Also, the old error message was out of date. You can't pass a function to the `ThreadPool` constructor.
player-03
changed the title
ThreadPool to manage both job types, run jobs soonerThreadPool to run jobs in both modes, and improve scheduling
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
There are enough use cases for both single-threaded and multi-threaded jobs that it's likely some users will want to use both. Before this PR, this required creating two
ThreadPools, one for each mode. Now, you only need the one.If you call
run()without passing the newmodeargument, it falls back to the pool'smode, producing the same behavior.I've also updated how jobs are scheduled. Previously, it would call
__startJobs()only once per frame. Now, it spins up new threads immediately if it hasn't hit the cap, and when a thread sends aCOMPLETEorERRORevent, the main thread will immediately reply with the next job. This is a little bit faster than waiting 1/60th of a second for the next__startJobs()call.On top of that, it can now run multiple single-threaded jobs per frame, including when one job's completion triggers the next.