►
From YouTube: Diagnostics WG meeting - Jan 15 2020
Description
B
B
D
E
E
Early
would
work
a
couple
of
times
we
try
to
setup
the
doodle.
We
couldn't
come
to
a
timeslot,
that's
acceptable
for
everybody,
so
one
of
the
suggestion
we
had
is
to
have
two
times
for
the
meeting
so
that
we
can
cover
everybody
without
starting
stretching
too
much
I.
Guess
that
is
still
a
possibility.
Let
me
set
up
there
good
doodle.
B
C
C
A
A
A
C
A
E
So,
from
my
perspective,
if
we
are
moving
shifting
ahead
by
one
hour
or
two
hours,
I
would
be
able
to
manage
attending
all
the
meetings.
I
mean
I've
been
stretching
like
that.
But
if
you
are
splitting
in
the
two
meetings,
I
would
prefer
to
have
a
more
convenient
time.
For
me,
that
is
like
some
fibers
head
of
the
current
time.
A.
E
C
B
A
B
A
Think
we
did
get
a
bit
more
interest
at
the
collaborator
summit,
so,
like
Giovanni
I
think
you
know
was
indicated,
he
was
gonna,
get
more
active
and
there
was
at
least
one
or
two
other
people,
so
maybe
she
would
like
other
than
like
broadcasting
her
or
trying
to
promote
that
we
want
more
people,
I'm,
not
sure
what
else
I
guess.
The
other
thing
is
there's
some
discussion
about
collaborator
summits,
sorry
and
that
seems
to
people
seem
to
be
interested
in
so
I
know
like
here.
A
B
E
E
B
A
F
E
It's
it's
a
mix
of
both
but
more
towards
needing
to
collaborate.
Basically,
people
who
wants
to
see
certain
capabilities
to
be
implemented.
The
best
example
was
a
sinkhole
right,
I
guess
there
are
quite
many
interest
on
that
and
they
want
to
see
it
being
out
of
experimental
and
having
the
right
performance
and
things
like
that.
I
believe
that
is
a
visible
category
which
we
could
see.
But
again
there
were
people.
There
was
real
consumers
who
want
to
see
certain
capabilities
implemented
as
well.
A
B
So
we
always
discuss
these
two
as
two
separate,
but
it's
I
mean
we
always
discuss
as
one,
but
it's
always
two
separate
here
so
I
feel
in
December.
We
kind
of
laid
out
a
plan
how
to
move
forward
and
we
assigned
people
to
definite
action
items.
If
I
change
my
rows
at
time,
do
you
see?
Do
you
see
the
new
the
meetings
from
December
notes,
yep.
A
B
B
Next
I
can
be
assigned
people
to
write
ups
for
usage
and
intelligence.
If
we
Paul
microbial
work
on
the
war
ground
matters,
Peter
will
work
on
the
air,
node
and
device
will
work
on
the
not
report.
So
that's
about
the
documentation
and
I.
Also
on
that,
we
were
working
on
a
process
crash
use
case
and
I
need
to
move
it
to
the
github
repository.
So
we
have
the
content
for
that,
just
need
to
move
and
the
people
who
sign
for
a
specific
kind
of
best
practices
guideline.
B
B
B
B
B
B
Okay,
we
can
yeah.
Does
it
sound,
reasonable
matters?
If
we
discussed
that?
Yes,
okay?
Well,
if
there
is
no
objection,
I
would
recommend
two
to
make
a
deep
dive
on
that.
Do
you
wanna
do
what
we
did
last
time
that,
like
we
use
the
usual
time
slot,
but
instead
of
going
through
the
action
items,
we
do
a
deep
dive
on
the
whole
meeting.
C
And
I've
been
working
on
a
few
things.
The
name
immediate
thing
is
Matteo
Kalina
had
so
the
like
current
resource,
API
that
he
was
working
on
that
side
for
a
while,
so
I've
been
updating
that
and
trying
to
get
that
definitely
landed
now,
it's
changed
a
bit
and
some,
like
other
stuff,
was
kind
of
fallen
out
of
that
for
more
stuff.
On.
C
Yeah
it,
it
has
some
performance
issues
that
I've
been
working
on.
Merging
okay,
I
created
a
separate
state
guy
for
like
pushing
and
popping
the
current
resource
from
the
reject
stack,
and
we
already
have
a
thing
for
pushing
a
popping
the
IDS
and
so
that
being
two
separate
calls
which
we're,
basically
all
in
the
same
spot.
It's
not
that
efficient,
okay,.
C
D
C
A
C
A
C
Know
so,
currently
a
vast
majority
of
triggers
of
the
async
cooks,
events
all
actually
are
effectively
initiated
from
the
JavaScript
side
and
then
go
into
native
to
do
whatever
activity
and
then
come
back
to
JavaScript,
but
to
do
the
trigger
and
then
go
back
to
native
again
and
then
come
back
to
JavaScript.
You
actually
do
whatever
that
task
was.
If
we
just
like
moved
the
wrapping
from
triggering
the
inside
of
both
plus
to
triggering
when
it
enters
C++,
then
we
could
actually
skip
like
several
boundary
crosses
to
would,
in
theory,
actually
be
a
lot
faster.
A
And
what
muscled
it's
making
me
wonder?
Does
that
make
you
know
the
discussion
we
had
before
around
the
like
a
more
generic
concept
of
async
context
and
possibly
bringing
that
to
be
like
a
JavaScript
level
standard
instead
of
you
know,
note
specific
this
having
moved
the
logic
to
the
the
GS
side,
to
help
in
any
way,
or
is
it
just
totally
tangential
to
that
and.
C
C
D
C
That
that
other
proposal
had
the
like
to
two
differents
like
two
different
paths
for
like
what
triggered
it,
what
triggered
a
thing
and
what
like
ultimately
caused
a
thing
and
that
that's
not
released
so
much
consideration
here.
It's
like
all
these
are
more
just
only
trying
to
get
as
much
as
propagating
the
bright.
A
A
I
didn't
I,
didn't
I,
wasn't
actually
thinking
that
those
other
PRS
necessarily
tied
to
Mike's
proposal
at
all
I
was
more
like
with
the
work
you're
doing
to
move
async
Hux
to
JavaScript.
Does
that
help
us
at
all
in
terms
of
getting
toward
making
progress
towards
that
proposal?
Slash
concept
and
I
wasn't
even
actually
thinking
the
other
ones
might
be
related
as
well.
I'll
have
to
go
back
and
think
some
more
about
how
how
that
relates.
C
Possibly
the
like
what
one
of
the
particular
reasons
why
I
want
to
move
a
bunch
of
s
and
cooks
to
the
JavaScript
side.
I
think
is
currently
like
the
like
one
of
the
biggest
things
that
has
prevented.
Asian
cooks
from
like
people
being
able
to
consider
it
as
stable
is
that
it
exposes
internals
through
the.
C
A
Okay,
well
I'll,
just
I'll
keep
my
question
to
once.
We
know
if
you
have
once
you
have
something
make
more
progress,
maybe
think
about
it
again.
I
just
I
liked
the
idea
that
if
we
could
end
up
with
something
that
was
a
broad
like
JavaScript
applicable
and
got
it
into
the
standard,
that
would
be
like
a
win
for
us
and
for
other
users
as
well.
F
Okay,
because
I'm
not
sure
I
know
it
will
work
for
promises
because
promises
II
is
specified
in
JavaScript,
but
for
callback
based
api's
and
event
based
api's.
I
am
not
sure
if
it
would
be
possible
to
including
the
specification,
because
it's
not
something
that
is
provided
by
javascript.
It's
something
that
browsers
and
implement
and
note
implement.
E
A
Same
things
like
not
not,
you
know
async,
not
these
in
coax
api
for
sure,
but
the
general
concept
that
you
know
you're
making
these
asynchronous
calls
and
that
you
know
the
spec
could
say
when
you
make
one
of
these
calls
you
need
to
retain.
You
know
a
virtual
frame
or
like
it
wouldn't
have
the
implementation,
but
it
would
say
you
need
to
be
able
to
preserve
this
in
this
information
and
provide
some
api
where
you
could
get
that
information.
Yeah.
C
A
A
C
Personally,
yes,
I
I
think
at
least
just
from
the
angle
that
it
lets
us
expose
it
more
at
the
level
that's
like
we
can
actually
stabilize
this
reasonably
and
also
like
it
being
JavaScript
and
I
got
I
got
that
level
to
interact
with
the
handle
who
want
to.
It
makes
it
easier
to
iterate
on
it.
I
think
I.
B
Mean
this
is
super
interesting
to
be
honest,
to
move
to
the
level,
but
currently
I
am
just
really
happy
that
Stephen
pick
it
up
agreed
so
about
that.
Like
do
you
need
help
from
the
working
group
somewhere
where
we
can
help
you
or
you
you
handle
it
or
how
do
you?
How
do
you
plan
this
this
work
or
you
you
handle
it
and
just
share
your
learnings
and
ask
for
some
feedback
or
like
yeah?
C
C
C
So
at
some
point
like
when
I
do
the
like
native
to
JavaScript
conversion
of
API,
that
will
be
fairly
big
and
complicated
so
that,
like
definitely
having
like
as
many
reviewers
as
I,
can
would
help.
Not
if,
if
anyone
has
much
from
me,
garetty
with
internals
I
think
it'd
be
helpful
to
you
have
have
some
some
people
that
can
jump
in
and
convert
certain
certain
spots
and.
C
So
I
want
to
just
wrap
those
functions
just
like
pass
that
function
into
another
function
that
triggers
the
before
and
after
automatically
like
on
the
JavaScript
side.
I
just
want
to
make
sure
that
that
is
reasonable
everywhere,
that
we
do
that,
but
I
haven't
gone,
really
beautiful
review
the
JavaScript
side
of
those
days
to
make
sure
that
actually
works.
Yet.
B
B
A
D
A
E
D
D
D
E
Second,
one
is
like
it's
currently
not
supporting
the
worker
threads
and
we
seems
to
be
having
some
attempts
to
collect
the
tracing
low-level
information
from
the
libuv,
but
it
it
was
in
successful
and
then
the
documentation.
These
are
the
main
pain
points
which
we
talked
about
from
the
tracing
perspective.
I
think.
E
F
I
have
tried
in
the
past
tree
to
use
some
and
usually
have
either
to
look
very
deep
into
the
documentation,
the
examples
or
looking
to
know
J's
code,
which
is
not
something
that
we
want
our
users
to
do
so
document
the
categories,
what
they
are
used
for
possible
performance
implications
of
activating
them.
It
is
probably
a
good
start
for
trace
events.
D
D
A
A
A
A
It's
this
one
I
just
paid
it
that
pasted
that
in
the
chart,
the
chat
you
know,
there's
some
there's
three
key
questions
which
I
kind
of
outlined
in
there.
One
is
like
there's
the
concept
of
like.
Should
this
be
in
core?
Not
there's
one
objection
to
that.
A
number
of
people
who've
chimed
in
saying
they
think
it
should
be.
A
A
You
know
the
the
fundamental
differences
is
one
is
naming
which
you
know,
I
think
that's
kind
of
a
bike
shedding
thing:
async
local
versus
async
context,
async
local,
is
I,
think
to
be
along
the
similar
lines
of
thread
local
and
it
kind
of
has
a
similar
idea.
You
just
declare
one
for
each
thing.
You
want
to
be
available
across
the
local
context
versus
say
a
local
thread.
A
Context
I
think,
has
more
of
the
the
notion
of
you're
running
in
something,
and
you
have
a
run
that
you
start.
You
know
you
say:
okay,
I'm
gonna
run
this
and
then
everything
that
does
run.
Is
it
as
a
result
of
that
in
the
context,
and
you
get
a
map
where
you
can
put
things
in
and
out
of
that
context
versus
than
being
separate
things.
A
A
Should
that
be
a
blocker
for
landing
the
API
at
all,
you
know
is
it
that
we
really
need
to
finish
that
first
and
then
we
can
layer
this.
You
know
whatever
the
right
is
API
on
top
of
it,
or
is
it
possible
to
land
an
API
which
uses
the
existing
functionality
and
have
you
know,
basically,
you
know
Stephens
PR
change
or
he
would
be
put
in,
and
then
the
API
B,
hopefully
no
external
API
changes,
but
the
internals
changed
over
to
use
that
so
it's
like.
Should
it
be
a
blocker?
It's
a
third
one.
A
C
That
what
I'm
working
on
it's
really
only
like
a
performance
improvement
to
them
or
they
bit
of
stability
improvement
like
yep.
There's
the
theoretical
memory
leak
situations
with
those
without
the
PR
I'm
working
on,
but
personally
I
think
that
like
if,
if
we're
landing
it
as
experimental
like
as
long
as
these
memory
leak
situations
are
not
impossible
when
you're
not
using
the
API,
then
I
think
it
should
be
fine
to
land
it
as
experimental
I.
Think.
A
C
A
Thaw
time
but
yeah
I
mean
that
would
make
total
to
me
I,
don't
think,
there's
gonna
be
any
rush
to
make
it
stable
like
we
want
to
test
it
out
in
so
that's
the
same
thing,
I'm
think
just
to
say,
I'm
thinking
along
the
same
lines
like
I,
don't
think
it
should
be
a
blocker
for
experimental
exiting,
certainly
would
be.
That
makes
sense.
Yeah.
C
C
A
That
could
make
sense,
though.
The
goal
with
this
is
to
have
an
API
that,
regardless
of
what
our
ultimate
implementation
is,
is
potentially
more
stable
right
like
not
necessarily
immediately,
but
it
exposes
less
than
we
do
through
a
see
hook,
so
it
might
be
easier
to
make
it
as
yeah
we're
comfortable.
We
can
continue
to
support
this,
even
if
things
change
very
radically,
underneath.