worker: refactor thread id management #25796
Closed
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
nodejs-github-bot
added
c++
joyeecheung
approved these changes
Jan 29, 2019
| Debug(this, "Set up worker with id %llu", thread_id_); | ||
| wrap->Set(env->context(), | ||
| env->thread_id_string(), | ||
| Number::New(env->isolate(), static_cast<double>(thread_id_))) |
There was a problem hiding this comment.
Now come to think of it, maybe this should be a BigInt?
There was a problem hiding this comment.
@nodejs/workers Thoughts? BigInt seems like it might be a bit much, but since it’s really just an identifier, that might be okay?
There was a problem hiding this comment.
In order to be relevant that'd require spawning more than 9,007,199,254,740,991 threads.
If we can spawn 1000 threads every seconds (a lot) and our program does nothing but spawn threads and we disregard any other limit or cleanup - it would take us ~285,616 years to exhaust that number of threads and overflow.
9007199254740991 / 1000 (threads per second) / 60 (seconds per minute) / 60 (minutes per hour) / 24 (hours per day) / 365 (days per year) = ~285616
If our machine is super fast and we spawn 100,000 threads per second instead, it would still take us over 2000 years. I certainly hope no one is going to run a Node.js server for that long.
I think a double is fine 😅
addaleax
force-pushed
the
thread-id-generic
branch
from
2235bae
to
adfebcc
Compare
|
Rebased due to merge conflicts, CI: https://ci.nodejs.org/job/node-test-pull-request/20418/ |
jasnell
approved these changes
Jan 29, 2019
benjamingr
approved these changes
Jan 30, 2019
lundibundi
approved these changes
Jan 30, 2019
- Assign thread IDs to `Environment` instances, rather than Workers. This is more embedder-friendly than the current system, in which all “main threads” (if there are multiple ones) would get the id `0`. - Because that means that `isMainThread === (threadId === 0)` no longer holds, refactor `isMainThread` into a separate entity. Implement it in a way that allows for future extensibility, because we use `isMainThread` in multiple different ways (determining whether there is a parent thread; determining whether the current thread has control of the current process; etc.).
addaleax
force-pushed
the
thread-id-generic
branch
from
adfebcc
to
38f26a3
Compare
addaleax
added
the
author ready
|
Sigh … rebased again. |
addaleax
added a commit
that referenced
this pull request
Feb 1, 2019
- Assign thread IDs to `Environment` instances, rather than Workers. This is more embedder-friendly than the current system, in which all “main threads” (if there are multiple ones) would get the id `0`. - Because that means that `isMainThread === (threadId === 0)` no longer holds, refactor `isMainThread` into a separate entity. Implement it in a way that allows for future extensibility, because we use `isMainThread` in multiple different ways (determining whether there is a parent thread; determining whether the current thread has control of the current process; etc.). PR-URL: #25796 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Denys Otrishko <shishugi@gmail.com>
targos
pushed a commit
that referenced
this pull request
Feb 10, 2019
- Assign thread IDs to `Environment` instances, rather than Workers. This is more embedder-friendly than the current system, in which all “main threads” (if there are multiple ones) would get the id `0`. - Because that means that `isMainThread === (threadId === 0)` no longer holds, refactor `isMainThread` into a separate entity. Implement it in a way that allows for future extensibility, because we use `isMainThread` in multiple different ways (determining whether there is a parent thread; determining whether the current thread has control of the current process; etc.). PR-URL: #25796 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Merged
This was referenced Feb 15, 2019
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.
Environmentinstances, rather than Workers.This is more embedder-friendly than the current system, in which
all “main threads” (if there are multiple ones) would get the
id
0.isMainThread === (threadId === 0)no longerholds, refactor
isMainThreadinto a separate entity. Implement itin a way that allows for future extensibility, because we use
isMainThreadin multiple different ways (determining whether thereis a parent thread; determining whether the current thread has control
of the current process; etc.).
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes