> > TJ Fontaine did a bit of experimentation with node-tracing, and Forrest > Norvell made CLS. Trevor Norris had also created AsyncListener to track > changes between async contexts. But all the approaches so far have been too > naive or simplistic and ultimately flawed. > Isn't this a bit of a red herring?
If you extend the language with an async/await construct (which is what streamline.js does), then the continuations are captured at the "language" level and you can instrument the language runtime to propagate a context across continuations and to track performance counters with "long stacktrace" semantics. This is completely transparent. The instrumentation service is provided by the "language" runtime and does not require any special support from the specific libraries that you are using (although I haven't tried it this way, streamline-flamegraph recording should work in the browser). If you don't extend the language with async/await then you need ad-hoc mechanisms. You need special mechanisms in node.js to propagate a context across continuations. This can be done in APIs like fs that are aligned on the continuation callback pattern but it won't work with other APIs that use events for continuation (for example a connect call that continues with connect/error events, or a read call that continues with readable/error events). I see a lot of effort being put in trying to provide context propagation features around raw callbacks (domains, long-stacktrace, async listeners). These APIs are of no use for people like me who are relying on a "language-level" construct and who get these features for free from their language runtime. They add complexity and they don't seem to hit their target (at least so far). IMO, raw callbacks should just be raw callbacks. They should be as fast as possible and they should not try to deal with context propagation. If developers want context propagation they should use a language extension (a la async/await) that captures the "continuation threads". They will also get other benefits (like robust exception handling). Better be explicit about what your program means (express your continuations with async/await) than rely on ad-hoc mechanisms that will try to reconstruct the continuation semantics from callbacks and special APIs. My 2 cents. Bruno -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/7a021f0f-0f7f-444a-b6e3-e30c27a4871f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
