Trace module WIP - Request for feedback

[joshgav]

joshgav/node-trace

Hi all. I've started designing and implementing a trace module/system for Node and wanted to get your early feedback. The goal for this module is to provide a common way for native and JS module authors to publish and/or subscribe to trace events both for debugging and logging; and to enable publishing traces back and forth to listeners on both sides of the native/JS boundary.

This could integrate with core TRACE_EVENT work in addition to ecosystem modules; for example, the TRACE_EVENT system could publish to the trace module to route traces to registered listeners. In fact I already implemented that elsewhere as a proof of concept.

Architecture

For now a whiteboard of the design follows; I'll work on something more formal.

Green outlines are JS modules; blue outlines are native artifacts. Black arrows show the flow of a trace published by a JS module; red arrows show the flow of a trace published by a native module or internal component.

The central classes are the native and JS TraceBroker classes (in the middle column), which receive published traces and publish them to a list of listeners they maintain. In both JS and C++ publishers call Trace/trace or TraceNextTick/traceNextTick to publish a trace. Listeners are function pointers registered via TraceBroker::RegisterListener in C++ and functions registered via EventEmitter.on in JS.

The JS TraceBroker class inherits from events.EventEmitter to handle listener management and event publication.

The native and JS brokers are wired together through the private DispatchJSFromNative and _dispatchNativeFromJS functions respectively.

The example (in ./examples) works and demonstrates the concept of a trace flowing from JS to both JS and native, try the following:

git clone https://github.com/joshgav/node-trace && cd node-trace
npm install
node-gyp rebuild
node ./examples/trace_example.js

But much work remains; tasks next on my list include the following:

• Add tests.
• Fill in placeholders in the code.
• Determine how to best transform C++ maps to JS objects and vice versa and implement.
• Add basic filtering in the brokers.

ASK: What do you think of the design? What concerns, e.g. perf, should I be thinking about? What similar modules or attempts exist which I could learn from or work with? And of course contributions are welcome :)

[rnchamberlain]

@joshgav I like the pub/sub broker design, and the support for JS and native. You mention filtering in the brokers, I am wondering how the trace flow is controlled. Say I write a listener and I am interested in trace from a couple of specific modules (and maybe v8 GC trace - see below). How do I enable trace in those modules and filter out trace from other modules that I'm not interested in?

Does integration with trace-event allow us to capture the output that's currently produced by v8 under the various/numerous --trace options? I guess that's a v8 question really, I have not worked out if/how those traces are connected with the trace-event API.

[gireeshpunathil]

should this remain open? [ I am trying to chase dormant issues to closure ]

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

[joshgav]

Can be closed, too dated to be of use. Thanks!