Skip to content

Latest commit

 

History

History
94 lines (65 loc) · 3.82 KB

2016-01-26.md

File metadata and controls

94 lines (65 loc) · 3.82 KB
Raw

January 26th 2016

Attendees

  • @trevnorris - Trevor Norris
  • @thlorenz - Thorsten Lorenz
  • @watson - Thomas Watson Steen
  • @pmuellr - Patrick Mueller
  • @bripkens - Ben Ripkens
  • @AndreasMadsen - Andreas Madsen

Agenda

Minutes

1:30 - agenda, previous minutes

5:36 - trace events

  • node branch now available to play with - issue comment

  • What work can we do in parallel to work Google is doing?

    • what will Google folks be providing?

  • What does a trace event look like in the code, including passing data?

  • How do we expose the trace buffer to whoever wants to read the trace events?

    • only via special build?
    • provided in existing node build, via native add-on?

  • What trace events do we actually provide?

    • very low overhead, and configurable, so we probably want to add a bunch
    • grouped via categories - a grouping mechanism provided by the tracing infrastructure

  • Probably don't want to have events themselves surface back through JavaScript, kills the overhead.

  • But probably want to think about configuring the tracing via some kind of API; start/stop tracing, configuring what trace categories are enabled, where does tracing output go. This API might be only exposed via native add-ons first, and then later higher in JS if we find a nice set.

  • What are the constraints on the data we can add to a trace event. Eg, presumably won't be pointers to things that can move / be freed, since trace events are "read" long after events occur.

  • Can we allow users to emit events from JavaScript?

  • Pat wants to create a couple of issues to focus on some of the particular questions.

    • how do expose trace events to the user
    • apis to start/stop/configure tracing
    • what are we going to put trace events around

31:07 - async wrap status