+yang who can say more about node.
We (Ben, Yang & myself) recently discussed the possibility of adding
coverage support to node itself. See here
<https://docs.google.com/document/d/1-BBdxe9_zIm9161_YQgKixL5mrM0rID9XuhcdDERYtA/edit?usp=sharing>
for a (very rough and early stage) doc with some thoughts.
On Wed, Aug 8, 2018 at 10:22 PM, demurgos <demurgos....@gmail.com> wrote:
> Hi,
> I work on Node.js code coverage tools using V8's profiler (c8).
>
> There are currently 2 methods to use the V8 debug protocol from Node.
> 1. You can spawn a process with the `--inspect` or `--inspect-brk` flag.
> This starts V8 in "server mode" and remote clients can connect to it and
> interact with the debugger.
> 2. You can use Node's "inspector" module to enable a process to debug
> itself (communicate with its own V8)
>
> This means to profile a V8 runtime, you need to first start the V8 process
> and then connect the inspector to it.
>
> This system causes a mismatch with the needs of coverage. nyc (istanbul)
> and c8 want to get coverage for all the node processes spawned in a process
> sub-tree.
> We have a single top process collecting coverage and each Node subprocess
> reports its results to it.
>
> This means that we have the opposite system: the inspector is started
> first, and then many debugged processes connect to it.
> But this is not supported by V8.
> So we use a "brutal hack" called "spawn-wrap".
>
> It intercepts all the Node processes created in a subtree and replaces its
> main module by another one. This wrapper module has the logic to start the
> profiler, execute the original entry point and then report the results.
>
> This solution is far from optimal. The wrapping mechanism is complex and
> hard to maintain, if the entry point forces the process to close
> immediately the reporting code is not executed, and the execution of the
> wrapper entry-point can interfere with the the coverage.
>
> Some of these issues can be solved, but the mismatch remains: we have to
> engineer a level on top of the V8 debugger because the connection can only
> go in one direction currently: the inspector connects to the debugger.
>
> I would like to know what it would take to support the opposite scenario:
> start an inspector server on some port (ex 9333) and then ask the debugger
> to initiate the connection.
> It would act like:
>
> inspectorServer.on("connection", (client) => {console.log("New connection"
> );})
> await inspectorServer.start();
> spawn("node", ["foo.js"], {env: {NODE_OPTIONS="--inspect-srv=9333"}});
>
> Ensuring that all the subprocesses have the same env var or flag is easier
> to achieve than hijacking the entry-point to emulate this kind of feature.
>
> I believe that this kind of feature needs to be implemented in V8. Am I
> right? Should I redirect this feature request to Node? Is it the right
> place to post this message?
>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
