►
From YouTube: Node js Tracing WG Meeting 2016-01-26
Description
notes at https://github.com/nodejs/tracing-wg/blob/master/wg-meetings/2016-01-26.md
A
A
A
A
A
So
I
want
to
I
want
to
think
a
little
bit
about
next
steps
there.
It
seems
like
there.
They
have
some
work
they
want
to
do,
but,
but
maybe
there's
some
stuff.
We
can
start
doing
in
parallel
start
thinking
about
what
this
means
to
us.
I
also
have
need
more
meat
structure
in
use
case
issues.
Actually
that's
been
a
that
melds
right
into
what
I
was
just
talking
about
in
terms
of
coming
up
with
thinking
about
what
we're
going
to
be
doing
with
trace
events
and,
let's
start
getting
some
use
cases
together.
A
The
only
other
item
on
the
agenda
was
a
sink
wrap
info.
I
believe
this
is
probably
from
andreas
who's.
Not
here,
so
we
can
have
Trevor
provide
any
info
on
that
if
he,
if
he
came
for
the
just
for
the
last
minutes,
looking
at
some
of
the
stuff
I
I
did
I
did
issue
a
pull
request
for
the
slide
for
the
work
group
and
the
Foundation's
getting
involved,
slides
there
I,
don't
think
that's
been
merged
and
there's
no
links
or
anything
there.
I'm
not
really
kind
of
following
that.
One
too
much.
A
A
For
the
for
the
trace
of
n
stuff
that
will
be
hitting
so
we'll
just
I'm
I,
don't
have
a
personal
interest
on
see.
This
is
sort
of
a
kind
of
strategic
thing,
big,
because
I
assume
that
part
of
looking
at
what
we'll
be
doing
with
trace
events
is
for
some
that
there's
some
way
we
can
tie
the
trace
event
new
work,
that's
going
on
or
we'll
be
going
on
into
things
like
LT
TNG,
so
that
they
can.
A
Metrics
statistics
think
so
I'm
not
I'm
not
like
real
hog
on
looking
at
that
other
than
if
the
any
work
is
on
here
would
be
interesting
just
as
a
sort
of
follow
one
for
how
in
fat,
how
will
affect
every
all
the
other
sort
of
tracing
things
going
on.
So
let's
talk
about
the
trace
events
stuff,
trying
to
think
there
is
a
tracking
issue
for
it.
It's
issue.
30
and
I'm
hoping
I
look
at
it-
okay,
so
I'll
need
to
make
a
comment
about
the
branch.
A
A
The
big
issues
are:
what
does
one
of
these
trace
probe
things?
Look
like
so
I'd
like
to
see
an
example
of
how
you
would
emit
a
trace
event
with
some
interesting
data
in
it,
because
I
believe
it
allows
you
to
put
some
interesting
data
in
there
and
then
so
so
that's
it.
So
let
me
make
a
list
here
things
that
are
kind
of
obvious.
What
does.
B
A
A
B
A
Especially
the
headphones,
really
quick,
hopefully
doesn't
lack
of
my
machine.
Yes,
okay.
So
a
great
question,
so
the
question
I
have
is:
how
is
the
bed
buffer
exposed
and
in
your
you
know,
or
that
question?
Is
it
exposed
or
two
who
write
to
who
is
it
exposed?
So
it
could
be
exposed
to
people
building
a
node
binary
through
some
kind
of
build
option
that
you
know
they
add
some
code
or
some
way
of
getting
access
to
it
or
it's
somehow
available
in
userland
right.
B
A
A
B
A
C
You
find
a
house
it
exposed
if
I
understand
correctly,
I
mean
what
they
want
us
to
do
is
just
implement
a
trace.
Portrays
conflict
trace
log
as
far
as
a
tracing
controller
right,
so
they're
basically
is
applying
us,
the
API,
how
this
works,
if
I
understand
correctly
and
I
think
we're
traversing
and
we
build
something
on
top
of
it,
that
we
can
expose
so
add,
ons
kan
hope
into
it.
They're
correct
Trevor,
mostly.
B
Yeah,
but
the
API
is
work
more
extensive
than
that
I
mean
they.
They
have
even
have
asynchronous
API
to
track
asynchronous
handles
over
time
itself,
a
cup
so
we're
trying
to
say
there
are
a
lot
of
different
hooks
we
can
put
in
and
so
I
think
that
the
biggest
the
biggest
discussion
will
be.
What
what
do
we
put
in
and
where,
because
since
since
this
has
so
little.
D
Yeah
I
would
really
like
to
see
something
like
this.
What
so
I'm
now
from
monitoring
background
coming
here
and
what
I
see
is
some
folks,
like
the
guys
from
node
source
with
the
end
solid
monitoring
tool,
they
ship
an
old
version
of
node,
which
is
seems
kind
of
invasive,
and
it
would
be
great
to
have
lots
of
these
little
pieces
of
information
that
most
of
these
folks
provide
in
node,
so
that
you
can
basically
reference
like
okay,
the
piece
of
information
we're
showing
here.
D
D
B
D
I
would
I
always
say
to
see:
is
you
open
up
monitoring
tool
their
various
once
and
you
always
have
to
figure
out
like
how
do
they
get
this
information,
and
is
it
the
same
one
that
you
see
in
monitoring
a
or
is
this
diff
differed
to
do
value
that
you
see
one
according
to
Abby,
and
how
did
you
get
this
yeah
having
the
standardized
way
to
get
this
information,
I
think,
would
clear
off
a
lot
of
confusion
about
stuff
that
you've
seen
these
monitoring
tools
would
help.
You
interpret
this
information.
Yeah
I
mean.
A
I
I,
certainly
that's
kind
of
part
of
what
I'm
looking
for
here
is
that
it
will
be
X.
The
stuff
will
be
hopefully
a
little
bit
more
visible
than
it
is
today.
I
mean
you
can
do
some
of
this
low-level
tracing
stuff.
Today,
torsten
has
all
kinds
of
crazy
demos.
He
can
show
you
of
playing
with
very
low
level
trace
stuff,
but
you
know
part
of
what
I
would
like
to
see
happen
here
is
that
it
does
get
exposed,
and
the
question
is
you
know:
where
do
we
expose?
It?
A
Trevor
is
probably
on
the
right
track
that
we
kind
of
start
started
the
kind
of
low-level
thing
and
maybe
provide
something
that
somebody
could
build
it,
a
native
module
to
be
able
to
access
this
stuff
and
then
over
time.
If
this
stuff
looks
like
it
would
actually
be
good
fit
in
core,
for
instance,
then
you
know
that
can
be
sort
of
a
follow-on
stuff,
but
but
starting
at
least
at
that
level
would
allow
you
know
anybody
be
able
to
play
with
the
tracing
adds
it
at
user
land.
A
B
11
issue
is
the
idea
of
exposing
it
the
JavaScript
API.
This
was
designed
to
be
very
little
if
any
overhead
asynchronous
processed
off
bread,
and
so
the
thought
of
bringing
all
that
data
back
into
the
main
thread,
just
to
admit
it
on
the
JavaScript
API,
seems
counterproductive
and
against
the
very
design
that
this
has
yeah.
A
Let
me
let
me
let
me
I,
guess
clarify
a
little
bit:
I'm
actually
not
expecting
anybody
to
be
reading
live,
trace.
Events
from
their
own
node
program,
I
think
you're,
absolutely
correct
there
that
it's
it's
going
to
be
overwhelming,
presumably
right
if
we
end
up
adding
a
lot
of
these
probes
and
there's
a
lot
of
events
trying
to
sort
of
read
what
your
program
is
doing
itself
is
tends
to
become
sort
of
problematic,
so
I
sort
of
expect
that
the
trace
events
are
going
to
get
put
somewhere.
A
Where
they
get
put,
you
could
imagine
a
file,
you
could
imagine
a
socket.
You
know
that
that
kind
of
been
but
I
also
think,
there's
perhaps
room
to
expose
api's
and,
let's,
let's
just
say
it
will
be
through
a
third-party
native
package.
That's
accessing
salut
know
C++
api's
to
do
things
like
start
and
stop
tracing
and
reconfigure
it.
So,
like
my
understanding
of
the
way
the
tracing
works,
is
you
have
to
sort
of
tell
it
what
you're
interested
in
and
then
it
will
kind
of
reconfigure.
A
The
tracing
stuff
live
in
a
very
performant
way,
so
you
can
sort
of
pick
what
you
want
to
be
able
to
trace
and
then
start
tracing.
If
you
want
to
change
what
you're
tracing,
then
you
would
have
to
stop
it
and
then
reconfigure
it
and
start
it
again.
So
I
would
expect.
Like
you
know,
what's
this
imaginary
v8
racing
third-party
native
module
might
end
up
having
some
api's
like
configure,
trace,
Star
Trek,
stop
trace.
A
B
The
the
idea,
one
of
the
fundamentals
of
the
api,
is
that
everything
has
categories,
and
so
just
exactly
like,
we
do
today
with
our
debug
function
in
court,
where
everything
is
labeled
and
then
you
can
specify
I
want
only
HTTP
calls
the
same
thing
with
the
tracing
API.
You
can
specify
a
category
or
set
of
categories
that
you
want
it
to
report
on
right.
A
And
so
this
this
notion
of
well,
what
categories
are
we
going
to
have
for
node
right?
So
presumably
there
will
be
some
for
b8,
like
compilation,
garbage
collection,
that
kind
of
stuff
and
presumably
will
want
some
in
note
as
well,
that
our
note
specific
so
that's
sort
of
part
of
the
question
of
well,
that's
one
of
the
questions.
A
A
C
Actually
issue,
as
far
as
I'm
Center,
the
whole
event
format
is
very,
very
simple.
All
the
3d
is
required
is
that
you
have
a
time
stem
right.
So
it's
like
this
line,
delimited,
JSON,
legged
of
events
and
each
one
has
a
time
stamp,
and
then
you
can
put
whatever
else
you
want
in
there
and
then
basically
just
a
tool
that
he
used
to
consume.
C
B
All's
under
ten,
except
some
of
these
racing
events,
have
up
to
seven
fields
that
need
to
be
filled
out
as
the
async
ones
specifically,
and
the
the
data
delivered
as
far
as
I
understand
from
holly
is
just
rod.
It's
that
need
to
be
parsed
out.
That's
why
I
turn
it
off
to
another
threat
to
be,
you
know,
turned
into
strings
and
whatever
that
can
actually
be
read
by
someone's.
A
Right
so
there's
constraints,
presumably
on
the
data
that
we
give
them.
It
has
to.
You
know,
survive
for
a
certain
amount
of
time.
Okay,
until
somebody
pulls
it
up
and
formats
it,
because
it's
going
to
get
you
know,
written
somewhere
and
then
later
somebody's
going
to
be
poking
through
it.
So
you
can't
just
give
it
some
sort
of
a
javascript
thing
that
would
end
up
getting
garbage
collected
or
moved
doesn't
matter
which,
because
it
won't
be
there.
C
Now
so
Trevor
okay
go
ahead.
I
was
just
wondering
so
basically
that
these
these
fields
that
you
have
to
add
to
these
a
cig
events.
Those
are
there
because
the
tool
that
is
going
to
visualize
this
once
these
fields
right,
it's
fast,
I
understood
you
could
also
have
like
custom
events
and
if
you
have
a
tool
that
knows
how
to
consume-
and
you
can
admit
whatever
you
want-
am
I
wrong
in
that
that's
what
my
initial
understanding
was
anyways,
that
all
you
need
is
a
timestamp
and
like.
B
B
B
A
The
alley,
or
maybe
even
Matt
from
way
back,
did
talk
about
some
kind
of
standardized
tools
to
print
this
stuff
and
they
were
expendable.
I
can't
remember:
I'd
have
to
go
back
and
listen
to
the
meetings.
I'm
I
doubt
any
of
that
stuff
got
written
down.
It
also
seemed
like
it
was.
You
know
not
necessarily
a
given
that
that
would
happen,
but
that
was
maybe
a
hopeful
thing
I'm.
I
guess
I'm
less
kind
of
worried
about
pulling
the
stuff
out
right
now,
because
I
assume
google
has
some
pretty
good
stories
around.
A
A
B
A
That
there's
all
macros
the
entire
thing
as
a
set
of
macros
yeah.
That's
what
I
thought
the
the
sort
of
fall
back
is
well,
you
could
always
create
a
user
1
user
2.
You
know
sort
of
category
and
then
allocate
them
to
people
who
need
them.
But
then
you
still
have
a
question
of
what
kind
of
data
are
they
going
to
be
able
to
put
on
there
right
I
know.
A
C
Going
to
say
on
a
high
level,
you
can,
you
can
admit,
I
mean
so
so
we're
talking
but
I.
Think
the
talking
about
maybe
two
different
things
like
one
is
like
the
low
level
implementation
to
buy
me
these
things,
but
then
what
actually
gets
transmitted
then
to
the
chrome.
Data
tools,
for
instance
in
this
case,
is
still
called
chrome
tracing.
C
B
C
Will
be
able,
by
the
times
I'm
spacing
to
align
them,
so
you
could
have
events
coming
from
C++
with
with
the
async
API
or
with
a
d-pad.
They
give
us
and
then
you
could
still
event
just
omit
additional
events
from
the
JavaScript
layer
and
make
sure
the
time
stems
are
in
sync
and
then
you
can
put
the
idea
together
and
you
can
store
then
read
that
as
one
thing,
but
that's
more
like
on
looking
at
the
high
level
at
actually
consuming
and
like
the
data,
the
actual
Jason
data
right.
A
But
you
know
imagine
you
wanted
to
you
had
some
sort
of
high-level
package,
the
red
files
you
wanted
to
mid
a
trace
of
n
every
time
you
process
the
file.
These
began
that
started
right.
What
kind
of
data
you
go
to
with
you?
Where
would
you
have
to
put
like
the
file
name?
Would
you
have
to
create
a
buffer
for
it,
and
then
you
know
arrange
for
that
thing
to
not
get
garbage
collected
until
after
the
trace
event
is
actually
converted
to
JSON.
A
You
know
what
I'm
saying
it
seems
like
a
very
tough
problem
to
me
and
the
less
I
unless
I
kind
of
know
more
about
the
categories
and
the
you
know
the
expectation
of
the
lifetime
of
pointers,
presumably
in
that
are,
and
so
these
trace
events.
It's
not
clear
to
me
that
there's
going
to
be
an
easy,
JavaScript
user
land
story
too
humid
of
X
I'm,
not
that
I
think
that's
fine.
We
don't
need
to
tackle
that
one
immediately,
but
you
know
would
be.
It
would
certainly
be
fun
to
kind
of
have
that
kind
of
capability.
A
A
A
How
are
we
going
to
expose
the
trace
events,
if
we're
going
to
do
something
different
than
what
Google
provides
api's
to
to
start
and
stopped
racing,
and
and
where
are
we
going
to
put
tracing
those
seems
like
kind
of
meaty
enough
topics
that
we
could
start
doodling
on
separately?
And
this
is
all
sort
of
precursor
to
get
us.
So
we
have
a
little
bit
of
momentum
and
kind
of
have
a
some
thoughts
about
where
we
want
to
go
once
this
tracing
stuff
kind
of
lands.
A
C
B
A
An
issue
30,
so
I
just
pasted
it
into
the
chat
they're
tracing
WG
is
30.
There's
almost
there
actually
go
and
look
at
what
we
should
probably
do
is
cut
and
paste.
What
do
you
put
in
near
the
bottom
of
issue,
38,
which
I
just
paste
it
in
with
the
quick
update
which
actually
describes
a
little
bit
of
what's
going
on
there,
because
the
fork
wasn't
much
to
go
on?
I
took
a
least
not
for
me.
I
took
a
brief
look
at
it,
but
I
I
quickly
got
lost
anyone
else.
E
Yeah,
yes,
I
will
try.
I
haven't
spoken
all
all
day,
so
I'm
a
bit
rusty
and
all
right.
So
the
first
item
is
about
getting
native
add-ons
integrated
with
Asian
rap.
So
there
was
some
work
on
that,
but
there's
a
lot
of
like
concerns.
Whether
or
not
we
really
want
to
expose
this
asian
grab
class
that
would
enable
it
and
add-ons
to
integrate
with
Asian
rap
is
so
real
like
what
is
the
status
here?
Do
we
want
this
class?
If
not?
What
are
the
alternatives?
E
B
Not
even
so
much
the
async
rep
class
is
the
one
it
inherits
from,
which
is
the
four
called
a
base
object
class,
which
is
like
fundamental
to
crew,
much
everything
and
exposing
that
you
expose
a
lot
of
internals,
because
it's
all
tied
to
the
environment
class,
which
is
internal
only,
which
means
that
it's
impossible
to
create
a
class
that
doesn't
expose
internal
methods
that
could
crash
your
application.
If
you
tried
to
run
them,
even
though,
technically
you
could
compile
your
application.
B
E
B
E
B
Necessary
that
is
a
freaking
nightmare,
so
so
I've
managed
to
get
may
call
back
mostly
well.
I,
haven't
managed
to
make
a
completely
reentrant
problem,
though,
is
that
if
you
have
an
error
handler
set
up,
and
you
run
a
call
back
through
make
call
back
execution
of
the
script
itself
like
so
with
domains?
If
you
do
domain
run
and
the
function
within
run,
Rose
execution
of
the
script
halts
that's
by
design.
Now,
if
you
run
a
function
with
it
and
make
call
back,
it
runs
synchronously
and
that
function
will
halt
execution.
C
B
B
E
A
A
A
Actually
do
something
useful
in
the
space
in
terms
of
trying
to
get
some
new
issues
created
for
us
to
have
as
discussion
about
some
of
these
higher
level
things.
So
it
looks
meaning
a
month
and
all
get
on
track
to
start
doing
a
google
and
whatnot.
For
that
anything
else.
I
may
want
to
talk
about
more
yeah.
F
B
Well,
we've
had
a
discussion
about
that
and
it's
been
decided
that,
since
it's
still
internal,
but
we
want
it
to
be
public
facing
that,
we
would
back
toward
all
the
changes
from
now
to
be
four
so
that
when
we
Lisa
documentation
for
it,
people
who
try
and
use
it
on
before
aren't
broken.
Okay.
That
sounds
really
great.
On
the
folks
left.