worker: correct (de)initialization order #22773
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
- Initialize `thread_exit_async_` only once the thread has been started. This is done since it is only triggered from the thread when it is exiting. - Move the final `uv_run` to the `Worker` destructor. This makes sure that it is always run, regardless of whether the thread is actually started or not. - Always dispose the `Isolate` before cleaning up the libuv event loop. This now matches the reverse order of initialization. Fixes: nodejs#22736
addaleax
added
c++
nodejs-github-bot
added
the
c++
refack
reviewed
Sep 9, 2018
| @@ -361,10 +361,19 @@ void Worker::StartThread(const FunctionCallbackInfo<Value>& args) { | |||
|
|
|||
| w->env()->add_sub_worker_context(w); | |||
| w->stopped_ = false; | |||
| w->thread_joined_ = false; | |||
|
|
|||
| w->thread_exit_async_.reset(new uv_async_t); | |||
There was a problem hiding this comment.
Question: why is this before the uv_thread_create? Maybe it's just a non intuitive name OnThreadStopped?
AFAICT uv_async_send(thread_exit_async_.get()) can only run iff the thread was created.
There was a problem hiding this comment.
Question: why is this before the
uv_thread_create?
Switching these would create a race condition – the worker thread might finish (and try to call uv_async_send() on this) before we have initialized the async
Maybe it's just a non intuitive name
OnThreadStopped?
Can you expand on this? It’s an event handler that’s called when the worker thread finishes.
AFAICT
uv_async_send(thread_exit_async_.get())can only run iff the thread was created.
That is correct, yes.
jasnell
approved these changes
Sep 10, 2018
|
New CI attempt: https://ci.nodejs.org/job/node-test-pull-request/17167/ |
addaleax
added
the
author ready
|
Landed in df7ebfa |
addaleax
added a commit
that referenced
this pull request
Sep 14, 2018
- Initialize `thread_exit_async_` only once the thread has been started. This is done since it is only triggered from the thread when it is exiting. - Move the final `uv_run` to the `Worker` destructor. This makes sure that it is always run, regardless of whether the thread is actually started or not. - Always dispose the `Isolate` before cleaning up the libuv event loop. This now matches the reverse order of initialization. Fixes: #22736 PR-URL: #22773 Reviewed-By: James M Snell <jasnell@gmail.com>
targos
pushed a commit
that referenced
this pull request
Sep 15, 2018
- Initialize `thread_exit_async_` only once the thread has been started. This is done since it is only triggered from the thread when it is exiting. - Move the final `uv_run` to the `Worker` destructor. This makes sure that it is always run, regardless of whether the thread is actually started or not. - Always dispose the `Isolate` before cleaning up the libuv event loop. This now matches the reverse order of initialization. Fixes: #22736 PR-URL: #22773 Reviewed-By: James M Snell <jasnell@gmail.com>
targos
pushed a commit
that referenced
this pull request
Sep 19, 2018
- Initialize `thread_exit_async_` only once the thread has been started. This is done since it is only triggered from the thread when it is exiting. - Move the final `uv_run` to the `Worker` destructor. This makes sure that it is always run, regardless of whether the thread is actually started or not. - Always dispose the `Isolate` before cleaning up the libuv event loop. This now matches the reverse order of initialization. Fixes: #22736 PR-URL: #22773 Reviewed-By: James M Snell <jasnell@gmail.com>
targos
pushed a commit
that referenced
this pull request
Sep 20, 2018
- Initialize `thread_exit_async_` only once the thread has been started. This is done since it is only triggered from the thread when it is exiting. - Move the final `uv_run` to the `Worker` destructor. This makes sure that it is always run, regardless of whether the thread is actually started or not. - Always dispose the `Isolate` before cleaning up the libuv event loop. This now matches the reverse order of initialization. Fixes: #22736 PR-URL: #22773 Reviewed-By: James M Snell <jasnell@gmail.com>
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.
thread_exit_async_only once the thread has beenstarted. This is done since it is only triggered from the
thread when it is exiting.
uv_runto theWorkerdestructor.This makes sure that it is always run, regardless of whether
the thread is actually started or not.
Isolatebefore cleaning up the libuv eventloop. This now matches the reverse order of initialization.
Fixes: #22736
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes/cc @nodejs/workers