inspector: supported NodeRuntime domain in worker #27706

alexkozy · 2019-05-15T01:21:33Z

NodeRuntime domain was introduced to give inspector client way to
fetch captured information before Node process is gone. We need
similar capability for worker.

With current protocol inspector client can force worker to wait
on start by passing waitForDebuggerOnStart flag to NodeWorker.enable
method. So client has some time to setup environment, e.g. start
profiler. At the same time there is no way to prevent worker from
being terminated. So we can start capturing profile but we can not
reliably get captured data back.

This PR implemented NodeRuntime.notifyWhenWaitingForDisconnect
method for worker. When NodeRuntime.waitingForDisconnect notification
is enabled, worker will wait for explicit NodeWorker.detach call.

With this PR worker tooling story is nicely aligned with main thread
tooling story. The only difference is that main thread by default is
waiting for disconnect but worker thread is not waiting.

Issue: #27677

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
commit message follows commit guidelines

nodejs-github-bot · 2019-05-15T01:21:35Z

Lite-CI: https://ci.nodejs.org/job/node-test-pull-request-lite-pipeline/3525

eugeneo

Thanks for working on this!

eugeneo · 2019-05-15T15:57:18Z

src/inspector/node_protocol.pdl

@@ -71,6 +71,11 @@ experimental domain NodeWorker
  # Detaches from all running workers and disables attaching to new workers as they are started.
  command disable

+  # Detached from worker with given sessionId.


nit: should be either "a worker" or "the worker". Not sure which :)

I added the since it sounds like there is the worker with given sessionId but I am open for any input from more proficient in English colleagues :)

eugeneo · 2019-05-15T16:01:14Z

src/inspector/node_protocol.pdl

@@ -71,6 +71,11 @@ experimental domain NodeWorker
  # Detaches from all running workers and disables attaching to new workers as they are started.
  command disable

+  # Detached from worker with given sessionId.
+  command detach


Do we need attach for symmetry? The problem I see is that we do not track worker separately from a session so introducing attach would definitely make it more confusing...

In this case should we have a little bit crazy NodeRuntime.disconnect method that works for main and worker thread?
I don't know any use case for NodeWorker.attach. Since workers are not waiting for attach by default, this method does not add any value without waitForDebuggerOnStart flag. Could we add it later when we know use case better?

One potential problem I see with the detach is that the worker is kind of "lost" once session is detached. A frontend may detach from the worker early and then there will be no way of attaching again. IMHO, attach can be implemented later if needed.

In this case should we have a little bit crazy NodeRuntime.disconnect method that works for main and worker thread?

Don't think this is necessary.

Feel free to ping me when someone would ask about this feature!

eugeneo · 2019-05-15T16:02:05Z

src/inspector/worker_agent.cc

@@ -115,6 +115,11 @@ DispatchResponse WorkerAgent::disable() {
  return DispatchResponse::OK();
 }

+DispatchResponse WorkerAgent::detach(const String& sessionId) {
+  workers_->Detached(sessionId);


Do we really need a detachedFromWorker notification in response to a frontend request?

Yes! It is how most domains (e.g. Target domain) in Chrome works. Notification means that worker session was detached for some reasons, one of the reasons might be explicit protocol request. It is easy to ignore this notification on frontend if needed.

src/inspector_agent.cc

NodeRuntime domain was introduced to give inspector client way to fetch captured information before Node process is gone. We need similar capability for work. With current protocol inspector client can force worker to wait on start by passing waitForDebuggerOnStart flag to NodeWorker.enable method. So client has some time to setup environment, e.g. start profiler. At the same time there is no way to prevent worker from being terminated. So we can start capturing profile but we can not reliably get captured data back. This PR implemented NodeRuntime.notifyWhenWaitingForDisconnect method for worker. When NodeRuntime.waitingForDisconnect notification is enabled, worker will wait for explicit NodeWorker.detach call. With this PR worker tooling story is nicely aligned with main thread tooling story. The only difference is that main thread by default is waiting for disconnect but worker thread is not waiting. Issue: nodejs#27677

nodejs-github-bot · 2019-06-01T13:31:36Z

CI: https://ci.nodejs.org/job/node-test-pull-request/23527/

nodejs-github-bot · 2019-06-01T22:39:04Z

CI: https://ci.nodejs.org/job/node-test-pull-request/23538/

nodejs-github-bot · 2019-06-02T13:01:12Z

CI: https://ci.nodejs.org/job/node-test-pull-request/23559/

alexkozy · 2019-06-02T19:37:40Z

Landed in 7e18c65

NodeRuntime domain was introduced to give inspector client way to fetch captured information before Node process is gone. We need similar capability for work. With current protocol inspector client can force worker to wait on start by passing waitForDebuggerOnStart flag to NodeWorker.enable method. So client has some time to setup environment, e.g. start profiler. At the same time there is no way to prevent worker from being terminated. So we can start capturing profile but we can not reliably get captured data back. This PR implemented NodeRuntime.notifyWhenWaitingForDisconnect method for worker. When NodeRuntime.waitingForDisconnect notification is enabled, worker will wait for explicit NodeWorker.detach call. With this PR worker tooling story is nicely aligned with main thread tooling story. The only difference is that main thread by default is waiting for disconnect but worker thread is not waiting. Issue: nodejs#27677 PR-URL: nodejs#27706 Reviewed-By: Eugene Ostroukhov <[email protected]>

NodeRuntime domain was introduced to give inspector client way to fetch captured information before Node process is gone. We need similar capability for work. With current protocol inspector client can force worker to wait on start by passing waitForDebuggerOnStart flag to NodeWorker.enable method. So client has some time to setup environment, e.g. start profiler. At the same time there is no way to prevent worker from being terminated. So we can start capturing profile but we can not reliably get captured data back. This PR implemented NodeRuntime.notifyWhenWaitingForDisconnect method for worker. When NodeRuntime.waitingForDisconnect notification is enabled, worker will wait for explicit NodeWorker.detach call. With this PR worker tooling story is nicely aligned with main thread tooling story. The only difference is that main thread by default is waiting for disconnect but worker thread is not waiting. Issue: #27677 PR-URL: #27706 Reviewed-By: Eugene Ostroukhov <[email protected]>

alexkozy requested a review from eugeneo May 15, 2019 01:21

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. labels May 15, 2019

eugeneo reviewed May 15, 2019

View reviewed changes

alexkozy force-pushed the worker-node-runtime-support branch from efa78cb to 2399bb8 Compare May 15, 2019 16:50

alexkozy force-pushed the worker-node-runtime-support branch from 2399bb8 to babdf80 Compare May 15, 2019 17:03

eugeneo approved these changes May 16, 2019

View reviewed changes

alexkozy closed this Jun 2, 2019

targos mentioned this pull request Jun 3, 2019

v12.4.0 release proposal #28040

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

inspector: supported NodeRuntime domain in worker #27706

inspector: supported NodeRuntime domain in worker #27706

alexkozy commented May 15, 2019 •

edited

Loading

nodejs-github-bot commented May 15, 2019

eugeneo left a comment

eugeneo May 15, 2019

alexkozy May 15, 2019

eugeneo May 15, 2019

alexkozy May 15, 2019

eugeneo May 15, 2019

eugeneo May 15, 2019

alexkozy May 15, 2019

eugeneo May 15, 2019

alexkozy May 15, 2019

nodejs-github-bot commented Jun 1, 2019

nodejs-github-bot commented Jun 1, 2019

nodejs-github-bot commented Jun 2, 2019

alexkozy commented Jun 2, 2019

inspector: supported NodeRuntime domain in worker #27706

inspector: supported NodeRuntime domain in worker #27706

Conversation

alexkozy commented May 15, 2019 • edited Loading

Checklist

nodejs-github-bot commented May 15, 2019

eugeneo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nodejs-github-bot commented Jun 1, 2019

nodejs-github-bot commented Jun 1, 2019

nodejs-github-bot commented Jun 2, 2019

alexkozy commented Jun 2, 2019

alexkozy commented May 15, 2019 •

edited

Loading