inspector: supported NodeRuntime domain in worker#27706
inspector: supported NodeRuntime domain in worker#27706alexkozy wants to merge 1 commit intonodejs:masterfrom
Conversation
nodejs-github-bot
added
c++
eugeneo
left a comment
eugeneo
left a comment
There was a problem hiding this comment.
Thanks for working on this!
src/inspector/node_protocol.pdl
Outdated
There was a problem hiding this comment.
nit: should be either "a worker" or "the worker". Not sure which :)
There was a problem hiding this comment.
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 :)
src/inspector/node_protocol.pdl
Outdated
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Feel free to ping me when someone would ask about this feature!
src/inspector/worker_agent.cc
Outdated
There was a problem hiding this comment.
Do we really need a detachedFromWorker notification in response to a frontend request?
There was a problem hiding this comment.
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.
alexkozy
force-pushed
the
worker-node-runtime-support
branch
from
efa78cb to
2399bb8
Compare
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
alexkozy
force-pushed
the
worker-node-runtime-support
branch
from
2399bb8 to
babdf80
Compare
|
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 <eostroukhov@google.com>
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 <eostroukhov@google.com>
3 participants
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), orvcbuild test(Windows) passes