►
From YouTube: 2021-04-23-Node.js N-API Team meeting
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
I
guess
the
only
thing
that
comes
to
mind.
We
may
have
mentioned
it
in
passing
last
time,
but
we
are,
the
team
is
doing
a
talk
at
opengs
world,
so
we
hope
to
to
see
you
at
the
conference
and
see
you.
You
know
hope
you
hope
you
watch
the
talk
on
on
note
note
api
and
I
think
registration
is
open,
so
I'd
recommend
and
suggest
anybody
who's
interested
to
go
and
register
now.
A
A
C
A
D
Right,
so
I
did
get
clarification
on
the
test
folder,
so
I
can
fill
that
in.
But
I
don't
I
don't
see
what
else
we
would
I'm
I'm
not
sure
what
else
needs
to
be
added.
I.
A
Think
it's
it's
more
like
converting
it
to
like
text.
D
B
D
I
did
there
taking
the
one
blurb
from
the
approach
above
and
just
expanding
it
just
a
little
with
an
example
or
so
so
in
my
mind,
I'm
not
sure
yeah.
A
D
Right,
I
just
left
that
up
there
as
a
so
we
could
compare
what
I
wrote
to
what
we
said
and
then
we
did
get
clarification
on
the
test
folder.
I
can
add
that
up
forgot
about
that
one
from
last.
A
B
A
A
B
B
B
C
C
C
A
D
C
Go
deep
on
all
the
motivation
yeah
can
I
can
read
this.
B
A
A
A
C
A
C
Okay,
I
I
send
in
the
email
later
and
if
okay,
I
can
for
sure
I
insert
you
on
cc-
maybe
all
the
team
I
can
include
all
the
the
team
members.
A
I
don't
see
anything
there.
Let's
just
move
on,
I
haven't
done
anything
in
terms
of
the
debug
testing
issues
related
by
module
owner,
so
this
one
I
do
want
to.
I
see
saw
kevin
that
you
had
done
some
work
on
that
intermittent
intermittent
issue
that
we've
seen
right.
D
D
When
we
left
last
week,
gabriel
had
mentioned,
you
can
try
to
use
a
mutex
in
order
to
synchronize
between
the
two.
D
Instead
of
using
time
okay,
so
then
I
tried
to
do
that.
Then
I'm
realizing
that
not
only
is
there,
we
would
need
to
synchronize
this
inside
the
c
plus
thread,
but
there's
also
some
some
time
stuff
being
done
in
the
javascript
thread
where
it
says
like
make.
This
thread
make
the
main
javascript
thread
busy,
so
that
right,
z,
plus
plus
thread
can
do
stuff,
and
I
think
then
I
also
have
to
do
some
synchronization
between
that
then
and
that's
sort
of
where
I've
I've
left
off
now.
B
D
A
Yeah
now
I
did
wonder
I
saw
that
failure
and
I
wondered
if
potentially
there
was.
We
have
multiple
things
going
on,
because
this
one
I
restarted
it
and
it
like
the
first
failure.
I
guess
maybe
I
shouldn't
have,
because
you
can't
see
it
now,
but
it
it
didn't,
look
quite
the
same
as
I
would
seen
before,
like
it
was
crashing.
After
all,
the
tests
completed
versus
right
after
the
tfsn.
A
D
D
As
I
was
doing,
investigating
the
failure
the
threat
say
function.
Export
was
actually
the
typed
thread
set.
A
B
B
A
I'd
be
tempted
like,
if
you
think
the
other
one
is
a
good
change
like,
because
removing
dependency
on
timing
is
always
a
good
thing
for
tests
right
so
like.
If
you
think
it's
a
good
change,
I'd
be
tempted
to
land
it
and
we'll
get
more.
Data
from
the
ci
runs
at
least
right
like
if
they
all
switch
to
being
the
one
at
the
end,
maybe
that's
slightly
different
right.
D
Right,
what
are
your
thoughts
of
modifying
modifying
the
test
to
output
to
iostream
with
it
if
it
fails,
instead
of
so
also
called
the
like
error
fatal,
but
then
also
output
to
iostream,
just
for
like
so
that
we
can
see
right.
D
A
A
D
A
A
So
and
I've
yeah,
I
just
wanted
to
talk
to
you
about
it,
but
I
had
looked
at
it,
so
I
would
say:
let's:
let's
get
that
one
landed,
I
can
also
once
that's
landed.
Try
and
you
know,
re-run
under
valgrind
and
see
you
know
it
may
have
been
that
the
the
timing
was
just
slower
under
valgrind
right
and
that's
why
we
saw
the
other
issue,
so
you
may
have
fixed
that
and
we
can
see
what
goes
on
and
if
you
want
to
yeah
create
another
pr
which
adds
some
extra
instrumentation.
A
A
D
And
the
third
one.
D
D
You
had
made
the
comment
that,
should
it
be
in
the
in
the
zip
file
in
the
git
file,
or
should
it
be
somewhere
else,
so
I
moved
it
into
my
compilation
unit
as
a
define
and
it
didn't
take,
and
I
think
it's
because,
when
the
method
throw,
as
javascript
exception
gets
compiled
by
some
other
caller,
the
first
time
the
compiler
goes
through
and
compiles
it
in
that,
setting
that
that
compile
option
isn't
set.
A
A
A
Let's
just
see
here
like
you
should
be
able
to
define
something.
That's
within
scope
of
of
you
know
a
single
file
even.
A
D
D
D
We
can
verify
right,
so
my
thought
is
that
when
we
compile
the
first
compilation
unit-
which
I
think
is
like
async
worker
or
something
that
uses
throw
as
javascript
exception,
and
then
it
would
be
compiled
that
symbol
without
that
compiler
flag
being
used.
A
A
B
D
D
So
then,
the
only
another
option
would
be
to
create
a
different.
A
different
target,
like
lucas
did
for
his
maybe
compilation
since
that
affected
everything
he
needed
to
create
another
target.
That
could
be
something
that
I
do
as
well,
but
then
that
would
increase
the
build
time
by
a
third.
D
B
A
A
It
should
fail
in
one
you
know
it
should
do
have
one
behavior
and
one
and
one
behavior,
the
other
behavior
in
the
other
one
because
yeah,
I
could
see
that
that
you
know
I
I
sort
of
getting
where
you're
we're
at
now.
If
we're
building
it
all
into
one
executable,
then
other
other
places
we've
done
the
import
it
may
have
already.
D
B
D
D
D
But
then
this
also
begs
the
question
like
we
see
now
that
that
the
defined
flag
cannot
be
set
on
a
per
compilation
unit,
it
would
have
to
be
done
on
like
the
whole
project
level.
Yeah.
Is
it
okay
for
it
to
be
like
that,
like
as
a
requirement,
a
restriction
to
the
developers
that
want
to
use
this
to
say
it's
on
your
whole
project
that
your
exceptions
would
be
swallowed.
A
D
A
E
A
A
D
D
E
A
C
So,
in
that
case,
we
we
we
will
have
four
four
build.
Is
it.
E
Everything
I
I
can
maybe
we
can
enabling
it
on
the
ci,
but
none
locally.
Let's
say
we
have
a
lot
of
tests
running
on
node.js
core,
but
we
are
not
running
them
locally,
right
like
say
a
sun
test
and
many
other
checks
and
debug
build.
We
don't
run
them
locally
very
frequently,
but
we
have
ensured
that
that
test
should
have
been
wrong
on
ci,
so
that
the
ci
is
running,
therefore
suite
and
we
can.
B
A
A
That,
actually,
that
would
be
yeah
you're
right
on
that
one
too,
although
I
think
legenda
cass's
point
was,
maybe
we
want
to
run
all
the
other
tests,
although
I
think
in
this
case
it's
like
it's
only
gonna,
it's
only
when
there's
an
unhandled
exception
that
it's
gonna
change
the
behavior
right
yeah.
So
I
I
I
think
we
could
probably
just
run
the
one
new
test
versus
everything.
D
Yeah,
can
we
go
to
the
files
changed
again,
because
I
think
I
had
a
question
on
the
fix.
I
think
yeah
a
little
up
yeah
here
when
we
get.
D
A
D
A
D
A
B
A
A
D
D
A
A
D
A
Yeah,
no,
that's
a
good,
that's
a
good
catch
and
okay
and
it
does
look
like
you
yeah.
You
deleted
the
part
that
I'd
commented
on
afterwards,
so.
D
A
A
That
sounds
good.
Were
there
any
others
that
issues
that
people
wanted
to
call
out.
A
E
E
Like
a
very
timely
idea,
strange
crashes
just
used
to
grow
the
app
sorry.
E
I
found
it
very
strange
that
we,
if
we
are
like,
say
we,
I
have
changed
all
the
tests
with
the
promises
so
that
the
test
will
run
running
one
by
one
and
unless
the
previous
one
is
already
finished,
the
later
one
will
be,
this
one
will
be
run.
So
then,
in
that
case,
if
we
are
disabling
the
async
hooks
in
their
destroy
callback,
we
will
get
a
strange
crash
on
the
not
call
in
the
callback
scope
check,
so
I'm
investigating.
E
The
pr
is
very
clean,
since
it's
already
positive
yeah,
I
have
a
and
yeah
everyday
walk
around
to
it,
but
you
can
decide
if
we
can
it's
like
say
it's
already
around
there
with
or
without
the
tester
new
test,
runner.
Okay,
so.
A
A
E
A
A
E
E
We
just
resolved
the
promise
with
a
new
async
stack
like
say,
early
independent
setting
double
stack,
so
it's
hard.
It
had
nothing
to
do
with
asynchronous.
B
E
A
Okay,
so
yeah,
I
know
I
can
see
how
that
okay,
so
does
anybody
have
any
concerns
with
with
making
that
change
like?
It
seems
like
a
good
one
to
me
for
sure
to
make
to
have
the
common
runner
and
and
make
it
basically
just
one
place
that
you
need
to
add
it
in
so.