Unfortunately, Google/V8 doesn't really care about nodejs. They only care about the browser, for which they deem the WebKit inspector to be sufficient. StrongLoop put so much effort into their node-inspector port of those tools for that exact reason. On Nov 12, 2014 11:39 AM, "Andreas Marschke" <[email protected]> wrote:
> +1 > > The important question here I guess is : How do you get these library > neutral instrumentations into the node runtime? Which is also what I > eluded to asking if would make sense to have people from v8 & node core > team together with people from the node-community at the same table and > start working out a standardize solution without stepping on each others > toes and make node and subsequently v8 a better engine to work with. > Imagine the benefits the browsers using v8 could foster from a central > orchestration of changes. > > Just saying. > > On 12 November 2014 13:54, Bruno Jouhier <[email protected]> wrote: > >> 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 a topic in the >> Google Groups "nodejs" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/nodejs/XYJih9Jv_40/unsubscribe. >> To unsubscribe from this group and all its topics, 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 >> <https://groups.google.com/d/msgid/nodejs/7a021f0f-0f7f-444a-b6e3-e30c27a4871f%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Mit freundlichen Grüßen, > > Andreas Marschke. > _________________________________________________________ > Web: http://www.andreas-marschke.name > Blog: http://andreasmarschke.wordpress.com > > -- > 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/CADq4APtj7MW6uJ%2BqipqT_1bBpddYU6ohgNJF1cw2V%3DrebtZbsQ%40mail.gmail.com > <https://groups.google.com/d/msgid/nodejs/CADq4APtj7MW6uJ%2BqipqT_1bBpddYU6ohgNJF1cw2V%3DrebtZbsQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CABcFeBW7PaS9jp_HzF5D%2BrQLAkvUK%3DOQQag9Z%3DcwLaTnKGfifw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
