Tracing WG Meeting 2015-09-25

[pmuellr]

Time: 3pm Friday September 25th UTC (8am Pacific), or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Tracing+WG&iso=20150925T15

Agenda and minutes can be collected in here and copied into this repo later:
https://docs.google.com/document/d/1c-mFv1WSAU4zB_p9B-5caCchv7dAqcx3kDGYVADUwgQ/edit?usp=sharing

Previous minutes: https://github.com/nodejs/tracing-wg/blob/master/wg-meetings/2015-02-19.md

Hangout on air for active participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYd0g141Sb2-hvEYks-aiPi37ArGfEDhE8fQS-Gvhh03gEPQUQ

Hangout on air for viewers, event page: https://plus.google.com/events/ceccr8614j3pg3rsqcq6ev4fsik

YouTube movie for observers and saved recording: http://www.youtube.com/watch?v=yM6q92V1IDk

Current invited participants, this list is not exclusive if you think you should also join:

• @pmuellr
• @lucamaraschi
• @Qard
• @yunong
• @matthewloring
• @AndreasMadsen
• @ofrobots
• @brycebaril
• @thlorenz

(will need emails for google docs/hangout setup - send to pmuellr@gmail.com)

Agenda discussion can happen in this thread.

(format copied from nodejs/Release#38)

(instructions for creating Hanouts On Air on the nodejs/node wiki)

[matthewloring]

@pmuellr I would like to join in on this meeting

[AndreasMadsen]

I'm not sure I will be able to make it, so I will just take an observer seat.

[lucamaraschi]

IN!

[pmuellr]

@matthewloring, @AndreasMadsen - send an email for the google doc / hangout, to pmuellr@gmail.com

[pmuellr]

I've added a number of folks for editing on the agenda doc, and on the newly created Hangouts On Air event. Let me know if you didn't see notice of this, and if the various links in the description don't work for you.

[AndreasMadsen]

This is the list of async_wrap issues that I could remember:

• There are some cases where it is not possible to know the context that created the handle: AsyncWrap: TCPWrap created before MakeCallback node#2986
• It requires monkey patching to catch errors without changing the throw origin:
  async-wrap: no way to catch errors without changing the throw origin node#669
• nextTick requires money patching: async-wrap: nextTick and setImmediate is ignored node#666 (closed, but still relevant)
• setTimeout, setImmediate, setInterval: shares the handle which results in an unexpected context: async-wrap: nextTick and setImmediate is ignored node#666 (closed, but still relevant)
• A handle ondestructed event would be nice. E.g.
  • clearTimeout(setInterval()) never notify asyncWrap. Will particularly be an issue when setTimeout "is fixed".
  • I belive net.connect() has a similar issue, the before and after event is fired multiply times, but you don’t known when the handle is no longer in use (connection closed).
  • (I need to revalidate these, but I'm quite sure they still hold)
• Deprecating process.binding will be an issue for AsyncWrap: node: deprecate public access to process.binding node#2768

I don't know how specific the meeting should be and some of these have already been discussed. So I will let someone wiser decide.

[pmuellr]

Guessing that @trevnorris has a fairly definitive list of async_wrap issues, but he unfortunately won't be able to make the call.

I don't know how specific the meeting should be and some of these have already been discussed. So I will let someone wiser decide.

I'm not wiser, but have some comments. :-)

At this point it looks like the "tracing" story has a few different angles - async_wrap, v8-tracing.h, platform specific tracing w/ETW/etc.

Seems like v8-tracing.h / platform-specific tracing are kinda at the same level, and async_wrap is kinda different. I guess I see it as async_wrap will be a great place to put v8-tracing.h / platform-specific trace points. Does that seem right?

If so, it would be good to come up with different "names" for these things, so we can keep straight what we're talking about, for folks coming to this as n00bs, like me.

In any case, w/r/t async_wrap, using it as an exemplar of using v8/platform tracing seems ideal. We clearly want tracing hooks there. So let's talk about it some.

Would also like to get an update on v8-tracing, from @ofrobots . @billti also provided some info on work to add ETW support for tracing to node, in #10, ICYMI.

[trevnorris]

Want to make sure everyone's on the same page about AsyncWrap. It is a class where I centralized the creation of all class constructors that have the possibility of performing I/O. The current API exposed via process.binding('async_wrap') was only created as a way to utilize the new class structure. That API could be removed easily without affecting the functionality of the AsyncWrap class.

• It requires monkey patching to catch errors without changing the throw origin

All error handling abilities were removed in the PR because of conflicts with the domain module and uncaughtException. Took me about a month to get it right, but was then considered to big of an alteration to merge at the time.

• nextTick requires money patching
• setTimeout, setImmediate, setInterval: shares the handle which results in an unexpected context

My original PR addressed these cases, but unfortunately they conflicted with domains and were eventually removed because I wanted to get the native code changes merged. This can be done, but requires making calls similar to how domains work today.

• A handle ondestructed event would be nice

This callback could not guarantee being called while the object was being destructed. Which means you would no longer have access to the object. I've toyed with an implementation in the past, but never reached a point of being useful.

• clearTimeout(setInterval()) never notify asyncWrap. Will particularly be an issue when setTimeout "is fixed".

This is because for performance there is a single TimerWrap instance with a JS linked list object attached that contains all the timers that will be fired in the future. So when a timer is cleared it's simply removed from the linked list.

• I belive net.connect() has a similar issue, the before and after event is fired multiply times

Probably because they are also creating a ShutdownWrap (src/stream_wrap.h). All *Wrap have a unique id, which could allow filtering of these calls.

Also note there are cases like net.createServer() that will not trigger AsyncWrap until .listen() is called. This is because we don't know whether the user wants a Pipe or TCP until that time. It was a serious pain to work around when I was writing the initial error handling implementation.

I haven't done much with AsyncWrap for a while because this is the type of conversation I wanted to have before proceeding. When should events be fires, in what order, etc. are things that need to be discussed.

[Qard]

Did you invite @bnoordhuis? He expressed interest in attending over in #19.

[Qard]

It'd be good to get @yury-s in there too, so we can discuss what needs to happen to keep nodejs/node#2546 moving forward.

[pmuellr]

I did not. I need to figure out how to maintain an email list from GH ids. And presumably Ben has a brand-new shiny IBM email id :-) Will send now. Both have email addresses in their GH profiles, so will send them a note.

[ofrobots]

I was trying to get @fmeawad to join the meeting. He's the chrome dev working on getting trace-event into V8, but I don't think he can make this particular time-slot.