►
From YouTube: Node.js Diagnostics WG - 2018-08-08
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
B
So
basically,
you
know
I
submitted
the
PR.
There's
been
a
bunch
of
discussion
earlier
I
think
just
yesterday,
if
I
remember,
maybe
the
day
before
I
updated
to
factor
in
all
the
feedback
so
far,
Joy's
chimed
in
with
a
little
bit
more
but
I
think
we
just
need
to
keep
pushing
to
the
point
where
people
are
comfortable.
B
C
A
C
A
C
A
C
This
is
the
API.
Was
the
ID
wouldn't
change?
It's
just
that
we
would
also
expose
a
resource
object.
That
will
be
that
we
could
use.
You
know
for,
like
I,
said,
weak
maps
and
and
in
different
prototypes.
It
would
actually
recover
performance
significantly
if
you
use
it
in
combination
with
a
weak
map.
B
C
The
original
design
was
that
we
would
still
have
to
do
straw
hug
people
case
the
register
destroy
hook
if
they
want
to
if
they
need
to.
But
if
they
don't,
then
we
wouldn't
fire
it,
and
that
would
also
save
you
know
we
wouldn't
have
to
allocate
a
persistent
handle
was
that
we
call
back
anymore
and
in
bieed,
and
that
would
make
things
a
lot
more
performant,
but.
B
C
A
B
A
C
Except
that
it
makes
a
lot
easier
for
me,
hg
c,
because
GC
only
cares
about
what's
alive
and
not
what's
dead,
and
if
you
want
to
destroy
hog.
What
actually
happens
is
that
the
GC
holds
on
to
a
list
of
week
like
week
list
of
objects
that
it
checks
every
time
after
GC,
whether
they
are
still
alive
and
if
they
are
not,
then
you
would
fire
a
district
and
keeping
that
list
and
going
through
that
list
is
costly.
I.
A
D
B
C
D
C
E
Ya
know
one
thing
that
was
mentioned
in
the
concerns
about
the
couriers
thing
was
I.
Don't
really
understand
why
it's
an
issue,
but
that
there
are
some
concerns
about
like
these
are
reused
source
certain
things
like
the
HTTP
agent
reusing
panels.
I,
don't
see
why
that
would
result
in
degrees
in
reviews,
though,
but
I
guess
that's
how
it
currently
works.
Maybe
four
sometimes.
A
C
C
So
there's
one
change
that
we've
been
I
want
to
do
in
the
age
but
haven't
had
time
to,
but
I
hope
we
can
get
it
done
until
node
11,
which
is
changing
the
promise
hooks
from
isolate
dependent
into
you
know,
per
isolate
into
per
context
so
that
you
can
use
J's
functions
like
JavaScript
functions
as
callback
Authority.
Instead
of
providing
C++
callbacks.
C
So
currently
the
v8
API
for
promise
bugs
takes
I,
think
four
different
C++
callbacks
for
different
or
not
no,
it's
just
one
simple
approach:
callback
with
different
from
a
subtypes
that
it
enhances
in
now.
Instead,
what
we
want
to
do
is
and
create
an
API
that
takes
four
different
JavaScript
functions
for
the
different.
A
C
So
those
would
be,
then
you
know
per
context
which
solves
a
bunch
of
issues
with
I.
Think
electron
has
this
issue
where
you
mix
contexts
and
and
then
we
will
also
directly
call
from
JavaScript
into
JavaScript
in
many
cases,
which
makes
it
cheaper,
because
we
don't
have
to
go
into
Super
Plus
anymore,
and
you
know
in
long-term
future.
We
could
even
imagine
in
dining
some
of
these.
C
Sorry
I,
don't
it
doesn't
directly
relate
it's
just
that
you
know
it's
a
it's
a
change
that
would
happen
in
parallel.
It.
A
A
Okay,
so
context
formalization
stuff,
we've
got,
you
know
like
a
PR
up
again,
it's
like
feedback
is
appreciated.
Like
I
said
we'll
schedule
a
deep
dive.
We've
got
a
deck
that
blocks
people
through
some
pictures
that
will
go
off
conversation
around
that
you
know
either
it's
like
nobody
cares
or
it's
super
complicated
or
you
know
we're
crazy
and
nobody
wants
to
tell
us
we're
crazy.
So
any
of
those
any
of
that
feedback,
whatever
it
may
be,
is
appreciated,
so
don't
hold
back
Oh.
D
A
You
know
I
think
the
the
goal
is
like.
Can
we
get
everybody
to
agree
on
the
terminology,
and
then
we
can
talk
about?
You
know
what
it
means
to
implement
it,
and
you
can
talk
about
how
this
sort
of
formalization
relates
to
async
looks
right
and
I
think
if
people
provide
feedback
on
this,
it's
useful
right,
and
so
let
me
see
if
I
can
paste
it
in
here.
A
So
the
last
thing
here
on
the
agenda
is
trace
events,
stuff
I,
don't
know
if
anybody
can
speak
to
anything
going
on
there
I
know,
I
saw
some
stuff
flow
by
and
email
and
James
was
working
on
stuff,
maybe
for
trace
events
around
some
of
the
new
promises
and
stuff.
That's
been
added
something
like
that.
C
So
there's
one
piece:
that's
a
little
bit
new
about
race
events,
so
currently,
I
think
nodejs
still
uses
a
default
racing
controller.
That
v8
provides,
which
is
a
very
bare
bone
implementation.
It
uses
some
sort
of
I
think
a
ring
buffer
and
it
has
race
conditions
in
there,
because
it's
just
very
basic
and
I,
don't
think
you
and
chrome
is
using
that
and
I
think
in
the
next
half
a
year.
C
We
want
to
switch
to
something
better,
there's
just
thing
called
perfetto,
which
was
being
developed
by
by
the
part
of
the
Android
team
that
works
on
Chrome,
which
is
supposed
to
be
this
unified
way
of
doing
tracing
and
it's
supposed
to
be
compatible
with
chrome
tracing
as
well
as
higher
supered
and
we're
thinking
of
switching
the
default
tracing
controller
in
v8.
To
that
and
Ali
is
actually
excited
about
that.
C
C
A
Okay,
so
I
know
that,
like
the
the
stability
issues
with
some
of
the
tracing
stuff
has
come
up
in
the
past
and
I.
Think
like
one
of
the
comments
I
just
read,
was
somebody
wanted
to
back,
for
maybe
some
the
tracing
stuff
and
someone
was
like?
No
don't
do
that
because
it's
not
stable
so
any
gives
to
this
default
tracing
provider
that
you
guys
have
in
v8
or
so.
C
The
default
tracing
control
is
really
just
kind
of
a
mock
right.
It's
just
a
ring
buffer.
Where
you
can
you
know
you
can
create
new
tracing
categories.
You
can
pull
with
the
the
ones
that
you
created.
Are
there
like
whether
you
enabled
them,
and
then
you
can
write
to
the
green
buffer
and
I.
Don't
think
there
is
even
a
way
to
read
the
ring
buffer
while
you
are
recording,
so
you
cannot
really
stream
anything,
and
it's
just
there
for
testing.