►
From YouTube: Diagnostics WG meeting August 25, 2021
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
B
Okay,
thank
you.
So
I
was
looking
on
the
node.js
asynchronous
documentation
and
it
says
that
is
a
module
that
provides
an
api
to
track
asynchronous
resources.
So
I
I
started
to
think
how
we
can
get
the
synchronous
resources.
B
I
mean
thinking
of
functions
in
general,
how
we
can
track
the
synchronous
functions
without
use
native
add-ons,
or
something
like
that,
because
I
was
thinking
that
we
can
maybe
try
to
create
some
kind
of
tool
to
make
a
difference
between
the
results
of
the
async
hooks
and
something
that
that
we,
we
can't
identify
the
synchronous
in
and,
for
example,
at
the
end,
let's
say
you
have
10
functions
that
are
synchronous
and
11
functions
asynchronous,
or
something
like
that,
because
I
was
looking
on
the
source
code
of
some
flame
graphs
projects
and
some
some
of
them
use
some
kind
of
native
add-ons
or
something
like
that.
B
But
others
don't.
So.
My
question
is
about,
if
that's
some,
some
hiding
or
whatever
api
in
node.js
to
to
be
able
to
look
on
the
synchronous
functions
executions
to
to
to
to
make
a
difference
with
a
synchronous
with
async
ac
hooks
to
make
a
difference
to
to
be
able
to
identify
the
the
executive
executed
functions,
the
the
synchronous
in
asynchronous,
I'm
not
sure
if
it
was
clear.
C
Yeah,
I
think
that
a
good
way
to
do
that
without
extending
to
native
modules,
is
measure
the
event
loop
delay.
Normally,
the
the
synchronous
cows
will
block
the
event
loop,
so
you
can
measure
which
function
is
taking
more
time
blocking
the
event
loop
and
then
you
see
which
function
is
doing
the
synchronous
resource.
C
I
look
in
here
to
check
if
there
are
some
some
way
to
get
the
function
name,
but
we
as
far
I
know
we
can
only
measure
the
event
loop,
the
event
loop
delay
as
a
percentage.
You
know,
but
also
you
can
check,
for
instance,
node
clinic
that
do
that
I
guess
I
have
eighty
percent
of
sure
or
others
profilers
like
zero
x,
that
you
can
see
which
function
is
taking
more
time
to
process
to
do
synchronous,
synchronous
resource.
C
C
So
I
would
say
that
there
is
no
way
at
least
I
don't
know
a
way
to
see
a
function
name
exactly
telling
that
this
is
a
synchronous
function
and
is
killing
your
app.
But
I
think
that
you
can
do
a
guess
based
adding
some
tools
like
know
the
clinic
or
do
a
profiling
with
flame
grabs.
B
Yeah
that
that's
a
really
clear
answer
I
mean,
let's
imagine
that
we,
if
it's
possible
to
have
some
flag.
B
I
I
know
that
makes
no
sense,
but
just
just
making
an
analogy,
there
is
no
kind
of
flag
to
say
that
this
function,
this
function
is
synchronous,
synchronous
and
that
one
is
a
synchronous
based
on
just
the
the
body
of
the
function
and
discarding
the
time
span
to
on
the
time
spent
on
event
loop
or
some
other
resource
right.
So
so,
but
but
at
least
that
that
is
a
good,
a
good,
a
good
start
point
we
can
we
can.
B
We
can
think
on
kind
of
we
can
think
on
kind
of
make
up,
make
some
experiments
on
on
this.
To
to
I
mean
I'm,
not
I'm
not
interested
in
the
flame
graph
percy,
but
but
the
the
names
of
the
function.
For
example,
you
have
these
three
functions
that
are,
we
can
call,
are
probably
synchronous
right
like
like
you
explained
it,
we
can
guess
we
we
we
have
no
exactly
flag
or
something
that
say
that
it's
possible
to
identify
right.
C
Yeah,
I
think
that
without
native
add-ons
we
don't
have
it.
At
least
I
don't
know
I
just
guessing
that
we
don't
have,
but
perhaps
we
have-
and
I
don't
know,
but
I
I
think
that
you
can
take
a
look
in
the
in
the
node
clinic
hold
know
the
clinic.
Do
that
under
the
hood.
And
then
you
see
if
this
is
from
native
code
or
js
only.
D
Yeah,
so
I'm
still
waiting
on
more
feedback
on
that
just
deciding
should
it
be
its
own
module
or
should
it
be
just
under
basin
cooks?
And
what
exactly
should
the
api
look
like
there's
some
like
different
suggestions
about
like
what
the
shape
of
the
api
should
be,
but
there
just
doesn't
seem
to
be
any
particular
agreement
on
on
anything.
C
Yeah,
I
I
did
a
review
there
and
I
think
that
the
the
the
final
question
is
how
the
api
should
looks
like
and,
and
the
other
one
is,
should
promise
hook,
be
nested
inside
asynchronous
module
or
should
be
exposed
in
a
different
module
right.
D
Yeah
yeah,
I
I
had
originally
put
it
under
acing
hooks
and
then
so
someone
commented
that
it
doesn't
necessarily
make
sense
there,
and
so
I
tried
pulling
it
out
to
its
own
separate
module
and
then
there's
concerns
about
it
being
a
top
level
module
and
there
there
seemed
to
be
like
some
statements
that,
like
making
it
a
top
level,
module
would
be
a
major
change,
but
that
wasn't
the
consensus
before
when
I
did
a
diagnostic
channel,
so
I'm
not
sure
like
if
something
has
changed
or
what's
what's
the
deal
with
that,
it's
yeah
like
the
intent
is
to
back
part
it.
D
C
There
are
some
someone
that
don't
agree
in
changing
the
the
api
to
be
more
simple,
simpler,
instead
of
be
based
in
a
syncrux.
C
There
are
someone
or
some
some
blocking
stuff
that
is
blocking
the
change
of
this
api,
to
looks
like
a
new
api
instead
of
be
based
in
async
hooks.
D
So
that
there
was
some
some
comments
that
it
might
make
more
sense
to
like
you
like,
using
an
object
style
api
like
the
the
same
sort
of
thing
as
asynchronous
has
with
the
like,
enable
and
disable
function
and,
like
it's
my
opinion
that
that's
actually
confusing
making
it
look
like
async
hooks,
because
it's
not
async
hooks
and
it
like,
has
like
several
subtle
differences
that
if
you
made
it
look
too
much
like
asynchronous
it'd,
just
be
confusing
because
it
doesn't
have
async
ids.
D
D
It
makes
more
sense
for
it
to
just
be
a
fully
separate
api
and
to
me
that,
like
lends
more
strength
to
like
it
should
probably
be
its
own
module
as
well.
C
Yeah,
it
makes
sense,
I'm
not
sure
what
we
we
are
supposed
to
do
like.
I
think
that
this
issue
is
waiting
for
review
for
a
long
time
right.
D
Yeah,
it's
been
like
sitting
just
paused
for
like
a
month
or
so
it's
yeah
the
one,
a
bit
of
uncertainty,
no
one's
really
giving
me
a
response
about
is
with
diagnostic
channel
I
I
was
able
to
like
reserve
the
diagnostics
channel
name
and
like
reserve,
the
name
in
it
again
npm
and
the
existence
of
that
allowed
us
to
create
the
module
in
car.
D
In
this
case
there
is
a
module,
but
not
not
the
same
name.
It's
like
it.
I
guess
npm
has
like
you
can't
take
names
that
are
similar
to
other
names
feature
and
so,
like
the
exact
name.
I've
chosen
doesn't
actually
exist
in
npm,
but
it
can't
be
taken
either
because
another
module
is
similarly
named
and
I'm
not
sure
if
that's
sufficient
for
us
to
use
that
name
or
if
we
need
to
come
up
with
a
new
name
that
we
can
actually
register
in
npm.
D
C
Oh
jewish,
can
you
promote
bradley.
E
E
That's
fine,
just
to
be
clear:
node
colon
is
reserved
now
in
node
core
in
both
require
and
es
modules.
So
you
don't
have
to
worry
so
much
about
names.
D
D
E
E
E
It
just
needs
to
be
available,
as
can
be
required
by
users.
So
most
internal
modules
are
going
to
be
that
and
then
we
just
have
to
set
it
up,
so
it
can't
be
used
without
node
calling,
so
we
actually
have
to
block
it
from
being
used
without
notice.
That's
it
the
check
for
that
would
be
in
the
two
resolvers.
You
can
just
look
for
the
node
colon
string
in
the
code
base.
E
D
Yeah,
okay,
yeah
I'll
I'll,
see
what
I
can
do
with
that.
D
D
It
gives
me
at
least
something
to
move
forward.
I
guess
and
yeah
just
any
reviews
I
can
get
and
just
comments
on
like
does
the
api
shape
seem
reasonable
would
be
helpful.
E
Oh
actually,
one
question:
this
is
kind
of
unrelated
to
promiseex.
Is
it
possible
to
instrument
these
hooks
off
thread?
I
guess
you
could
always
spin
up
a
worker
and
do
stuff
in
the
worker
instead.
D
E
D
Not
not
exactly
sure
what
you
mean,
but,
like
don't
worry,
it's
not
important
yeah.
You
you'd
have
to
call
the
set
promise
hooks
from
like
whichever
context
you
want
to
listen
to
promises
from
those
received
promises
like
yeah,
you
could
probably
send
those
to
another
thread
or
something
or
like
send
them
to
worker
threads.
I
think
I
think
they're
transferable
objects
so
yeah.
A
C
C
Yeah
the
this
one
is
one
of
the
tutorials
and
the
other
pr
is
about
adding
the
debugging
black
box
section,
and
I
think
that
both
both
was
approved.
So
it's
just
to
make
sure
that,
shall
I
merge
or
I
need
to
wait,
someone
to
merge,
go
ahead
and
merge.
C
C
D
Yeah,
I
think,
there's
been
a
couple
more
comments
in
the
issue.
That's
not
nothing
that
we
weren't
already
aware
of.
D
Yeah
yeah
yeah
there
seems
to
have
been
a
few
people
that
came
from
the
blog
post.
I
guess
left
some
comments,
but
yeah
it's
it's
mostly
just
kind
of
reiterating
stuff,
we've
already
considered.
D
A
So
are
we?
What
is
the
next
step
here?
Are
we
planning
to
wait
for
some
more
time
to
see
new
unique
use?
Cases
on
async
local
storage
will
be
coming,
or
we
should
take
a
call
to
say
that
these
are
the
identified
use
cases
and
we
floated
it
across
to
collect
the
other
new
use
cases
that
people
are
aware
and
that's
it.
So
we
are
deciding
that
these
are
the
set
of
use
cases.
D
D
Do
we
like
mark
ace
and
cups
as
like,
deprecated
or
legacy,
or
something
to
like
signal
to
people
to
like,
maybe
use
other
like
use.
Something
else
use
other
apis.
B
Yeah,
I
I
think
just
a
side
comment.
I
think
that
that
tweets
had
a
lot
of
engagement.
Maybe
maybe
do
some
tweet
like
this
sometimes
later
makes
sense.
I
I
don't
know
because,
because
I
I'm
you
know,
I
I'm
funny,
and
probably
you
you
guys
too,
the
node.js
tweeting.
The
numbers
are
pretty
impressive
for
five
days
right
until
now,.