inspector: introduce inspector.SyncSession

[joyeecheung]

This patch introduces a synchronous inspector session that
dispatches the message and returns the result synchronously
to the user.

Checklist

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[addaleax]

Is the main difference to regular sessions that the result is returned from .post()?

[joyeecheung]

@addaleax Yeah, that makes the invocations that intend to use the results synchronously looks less awkward. I'll still need to investigate if this make sense for most methods, though.

It seems inevitable that this has to be an EventEmitter to send out messages/notifications that are not triggered by a particular .post, I think that's probably the best abstraction we could end up with for these anyway?

I'll need to complete the docs before sending it out for review..

[targos]

Isn't it enough to add a postSync wrapper method to the existing class? I don't think we need to optimize for performance here.

[eugeneo]

Chrome team considered the fact that all V8 inspector messages are processed synchronously an implementation detail and there was specific goal not to make it a part of the interface. Chrome already has some asynchronous inspector calls outside the V8 domains.

Promisifying this interface would be the correct way but so far it had not been possible due to the inspector restrictions (event loop may be paused while the messages are being processed)

I am concerned that this interface will be broken down the line, as JavaScript evolves or other domains are being added to the Node Inspector.

[joyeecheung]

Isn't it enough to add a postSync wrapper method to the existing class? I don't think we need to optimize for performance here.

@targos Note that in the implementation, the sync variant uses Function::Call instead of MakeCallback to avoid triggering any microtasks or tick callbacks, or emitting any async hooks before returning the result to the user (which seems counterintuitive for a synchronous session). It's easier to implement this on a per-session basis, because the onMessage callback that connects the C++ and the JS land is per-session.

[joyeecheung]

Chrome team considered the fact that all V8 inspector messages are processed synchronously an implementation detail and there was specific goal not to make it a part of the interface. Chrome already has some asynchronous inspector calls outside the V8 domains.

Does this apply to all commands? There are commands explicitly marked as async in the protocol configuration, so I assumed that commands that are not marked are synchronous. We could also throw errors for those commands in the synchronous session, when we end up having to implement those asynchronously.

I am concerned that this interface will be broken down the line, as JavaScript evolves or other domains are being added to the Node Inspector.

Would changes like that affect existing commands, or would they be added to the protocol as new commands? I believe if the commands have to return the result asynchronously, they would not look the same as they are now. Take heap snapshots for instance, even if you dispatch HeapProfiler.takeHeapSnapshot synchronously, you would not have the result immediately but instead have to listen to HeapProfiler.addHeapSnapshotChunk. So even if heap snapshots can be returned synchronously, you can force the users to handle them asynchronously by how you design the commands. If a result of a command has to be returned asynchronously, the command can be designed not to return the result immediately but instead deliver the result in events (I believe Debugger.pause / Debugger.paused also work that way).

If we end up having to return results of commands asynchronously in their own invocation, would it be possible to keep them separate from the synchronous ones, so a synchronous session still works for commands that don't have to be asynchronous? (from what I can tell from the templates, the async commands and the synchronous commands already have their code generated differently, it just happens that the async ones are also implemented synchronously in Node.js).
The commands themselves come from the inspector protocol, so the stability guarantee of that is out of the scope of Node.js and the users should expect changes there anyway - we could also make that clear in the docs.

[addaleax]

Fwiw, takeHeapSnapshot is synchronous as well, and I think it would actually be difficult to implement it asynchronously?

[eugeneo]

Does this apply to all commands? There are commands explicitly marked as async in the protocol configuration, so I assumed that commands that are not marked are synchronous. We could also throw errors for those commands in the synchronous session, when we end up having to implement those asynchronously.

Yes, all commands are async. I am not sure what you mean by "protocol configuration" - if that is inspector_protocol_config.json then it is not a spec but a code generator configuration file, telling the code generator to pass in the callback instead of expecting a synchronous return value. In some cases in Chrome we flipped that switch as a part of an optimization or a refactoring effort and that did not require any change on the frontends. Note that the protocol viewer does not differentiate "async" and "sync" calls.

Also, I believe it will be hugely confusing if some messages would work through this API and some would not.

Fwiw, takeHeapSnapshot is synchronous as well, and I think it would actually be difficult to implement it asynchronously?

All messages are considered async, no message is supposed to be safe from becoming async...

[joyeecheung]

For context, this came out of the discussion in https://chromium-review.googlesource.com/c/v8/v8/+/1546559

If we can't rely on the premise that we are able to use the inspector synchronously (wether exposed as a public API or not, at least for the commands we need), then we cannot rely on inspector in util.inspect(), and either need to implement embedder APIs for what we need, or only use the inspector in console (with functionality mismatch in util.inspect()) , though that'll transitively make the TTY console async, which could be breaking (but I don't know about the potential breakage...it's hard to imagine a hard dependency on console.log being synchronous, but it may introduce some ordering differences in existing code that confuse people)

[gengjiawen]

Should we add docs for this change ?

[joyeecheung]

I won't be writing docs until I confirm this feature actually makes sense..
(now I am leaning towards no)

[targos]

What do you think about making this an internal feature only (for use in inspect an maybe tests)?

[joyeecheung]

What do you think about making this an internal feature only (for use in inspect an maybe tests)?

If the synchronicity can be broken, then we can't really build features that depend on this, right?

[joyeecheung]

I am going to use this PR (switched to internal as mentioned in #27110 (comment)) for the basis of an inspector-protocol based version of private fields inspection (#27404) given the feedback we've got from V8.

TL;DR: the suggestion was to build on top of the current synchronicity of the inspector implementation in util.inspect for now. Should the circumstances change we'll revisit whether it's better to expose APIs in V8 to work around any breakage.

[joyeecheung]

I think a better plan for now is to publish this as an npm package instead of bringing it into core

[gengjiawen]

I think a better plan for now is to publish this as an npm package instead of bringing it into core

publish it on npm may not bring enough attention.

[antsmartian]

@joyeecheung Is this something we wanted to revisit again or as mentioned in comments, this shouldn't be in the core but to be part of a npm package?

[joyeecheung]

@antsmartian yeah, I don’t think this should be in core at the moment.