►
From YouTube: 2021-11-05-Node.js Node-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
B
I
have
been
speaking
with
the
author
in
a
chat
and
I'm
trying
to
ask
him.
Well,
I
asked
him
if
how
to
reproduce
the
crash
that
he's
seeing
because
of
the
deletion
of
the
reference
object,
and
he
says
that
it
requires
a
more
complex
interaction
than
what
the
test
has
and
and
in
fact
no,
it
doesn't.
But
in
the
test
that
same
interaction
succeeds,
whereas
in
the
real
world
it
breaks
and
so
he's
gonna
try
to
come
up
with
the
repro
that
he
can't
post.
A
Okay,
well
thanks
for
the
update,
that's
good
you're
on
top
of
that
with
them.
Okay,
the
next
one
is
our
stale
issues
to
discuss.
So
we
have
the
reple
issue.
A
C
A
Okay,
so
there's
still
a
few
comments,
I
guess
to
be
addressed
so
on
that
one,
basically
we'll
just
wait
till
that
makes
progress.
So
that's
fine,
this
one,
which
is
how
to
make
construct
nappy
callback
info
c
plus
plus.
We
did
talk
about
that
la
that
one
last
time.
If
I
remember
we
posted
on
that,
so
there's
no
answer,
so
I
guess
nothing
to
talk
about
on
that
one,
and
I
think
I
added
this
one,
because
I
think
it
was
just
recently
marked
the
stale.
A
A
A
Still
some
growth
there,
let's
see
okay
back
to
nothing
too
much
to
discuss
on
that
one
we
don't
have
jack,
so
won't
ask
about
the
tested
method,
which
I
know
he's
working
on.
Deepak
do
you
have
anything
to
for
us
to
discuss
on
the
work
related
to
the
test
framework.
D
No,
my
god,
I'm
just
waiting
for
you
know
to
merge
the
pr.
If
gabriel
and
kevin
are
okay,
we
can
merge
the
pier.
A
Right
so,
let's
just
take
a
look,
I'm
in
the
wrong
one.
There.
A
D
Perspective
there
was
only
one
outstanding
comment
from
kevin.
He
was
fine
with
everything
else
he
was
asking.
Why
do
we
need
two
environmental
variables
for
a
relative,
build
path
and
build
path?
I
had
responded
to
that.
I
feel
that
we
need
it.
That
was
the
only
outstanding
minor
comment.
Everything
else
is
addressed.
D
A
D
Yeah
there
are
two
places
in
in
the
test:
folder,
where
we
need
the
build
path.
One
is
a
place
where
we
run
the
tests
there.
We
need
the
complete
path
because
it
is
just
it's
it's
trying
to
go
to
a
with
the
root
right
without
a
root.
Basically,
it's
going
without
a
without
without
a
root
yeah,
so
it
doesn't
have
a
root
and
it's
trying
to
point
out
build
a
path
without
root,
so
it
needs
a
full
path
right.
D
So
that's
the
build
path,
so
I
need
a
full
path
there
and
then
there
is
one
more
location
which
I
have
been,
which
I
have
pointed
there
in
the
comments,
and
so
that's
the
index.js
under
test
where
there
is
a
root
and
then
the
root
is
so.
The
the
root
test
path
is
then
prefixed
to
the
build
path
right.
So
it's
just
something
like
a
prefix
and
then
the
build
path.
So
what
I
am
doing
is,
I
am
injecting
a
relative
builder
path
there.
D
So,
okay
yeah,
so
I'm
not
sure
if
there's
a
way
to
minimize
that
with
with
just
one
bill,
but
I'm
trying
to
think
of
it.
Maybe
if
I
am
I'm
not
sure
I
thought
this
is
the
best
approach,
I'm
not
sure.
If
that
is
any
other
way,
I
can
simplify
that.
D
A
few
of
the
other
things
are
linting
comments,
the
files
that
I.
C
A
A
D
Outstanding
comments,
yeah.
D
B
Okay,
okay,
okay,
okay,
all
right,
so
the
the
other
one
I
did
the
other.
The
other
comment
I
had
so
far-
and
I
haven't
looked
through
all
of
it-
is
that
there
is
no
reason
to
to
just
rename
environment
variables
on
the
command
line
like
you
have
like:
filter
equals,
npm
dollar
npm,
config
filter,
and
then
you
run
the
command
line
right
yeah.
I
think
I
think
it
would
be
simpler
to
to
do
that
to
make
that
rename
inside
the
javascript.
B
D
When
I'm
passing
yeah,
when
I'm
passing
a
filter
variable
from
the
command
line,
it's
it
gets
into
the
npm,
build
as
npm,
and
I
think
npm
config
right,
yeah,
that's
fine!
Okay,
okay,.
B
D
Okay,
cool,
okay
I'll
make
that
change.
Then
I
thought
so
that's
why
I
was
trying
to
reply
to
you
that
you
know
within
the
code.
It
must
makes
much
easier
to
just
refer
to
that
as
filter,
because
we
are
passing
from
the
command
line
filter
but,
like
you
said
on
the
top
of
the
command
line,
probably
I
can
translate
it
exactly.
D
In
the
javascript
to
filter
from
npm,
okay,
cool
yeah,
yeah
agreed
yeah.
I
agree
that
I'll
make
that
change
now
I'll
make
that
change
and
notify
you
probably,
then
we
can
merge
it.
D
Yeah
we
can
either
meet
offline
I'll,
send
you
a
mail.
If
you
have
any
more
concerns,
we
can
even
meet
offline
and
then
I
can
go
over
the
changes
and
maybe
we
can
then
take
a
decision.
A
Okay,
people
debug
haven't
done
that
so
then,
looking
at
issues
raised
by
module
owners,
I
don't
know,
are
there
any
that
people
have
on
the
top
of
their
their
mind?
That
are
new,
where
we
should
talk
about.
A
E
We
just
in
the
same
change,
to
add
to
all
other
typed
errors
like
is
it
found
in
javascript
spec.
E
Should
be
relatively
limited
if
you
probably
follow
this
mdn
link,
eval
error,
internal
error.
B
Can
we
go
yeah?
Is
there
like
a
way
to
get
some.
B
B
E
I
think
a
new
compatible
javascript
implementation
probably
will
must
have
this
errors
anyway,
and
it's
good
and.
A
B
A
A
A
It's
basically
is
it
safe
to
use
nappy
add-on?
Basically,
is
it
safe
to
use
nappy
add-on
and
nappy
object
wrap
together?
I
didn't
have
time
to
think
about.
I
think,
gabriel.
You
might
have
a
thought
on
that
off
the
top
of
your
head.
B
A
Okay,
so
you'll
answer
that
I
will
go
on
to
this
one.
I
know
another
one
so
kevin
wanted
to
discuss
this
in
the
meeting,
but
we
don't
have
kevin.
So
maybe
we'll
wait.
I
don't
know
chenzong
or
legenda.
Cassie
have
anything
to
add
to
this
one.
A
A
E
I
have
a
good
question
about
as
I'm
kind
of
working
on
this
implementation
for
napi
for
hermes
and
about
this
of
analyzers
again,
so
I
talked
with
herms
team
and
one
of
the
options
to
implement
this
more
reliable
finalizers,
so
think
how
how
penalizers
work
today
for
v8.
So
the
work
not
done
immediately
as
garbage
collected
our
object,
but
instead
we
kind
of
submitting
our
callback
to
so-called
like
a
second
pass
callback
or
something
this
and
then
against.
E
The
v8
has
some
kind
of
special
second
pass
and
it
can
run
all
different
callbacks
right.
So
currently,
there
is
no
such
mechanism
in
hermes
and
there
are
different
possibilities.
How
we
can
implement
it,
because
we
can
change
something
cannot.
But
I
wonder
what
do
you
think
about
using
microtasks,
because
from
the
hermes
developer's
point
of
view,
it
will
be
one
of
the
safest
options.
So
imagine
that
then
we
need
to
finalize
an
object
to
effectively
run
our
custom
finalizer.
E
B
B
E
Oh
sorry,
okay,
so
thank
you.
It's
about
running
finalizers,
napi,
node
api
finalizers.
Today
in
v8
they
run
as
a
part
of
special
second
pass
stuff
in
v8.
E
E
So
imagine
like
in
this
case,
say
like
we
can
just
simply
submit
any
kind
of
analyzers
as
a
special
microtasks.
If
you
will
and
then
with
microtask
loop
goes
on
we're
kind
of
executing
all
these
finalizers.
So
so
thank
you.
There
are
two
benefits.
First
of
all,
at
this
point,
the
whole
system
can
be
definitely
the
reliable
state
and
we
know
that
no
nothing
goes
on
in
the
middle.
E
Secondly,
microtasks
is
a
rather
standard
mechanism,
so
any
kind
of
javascript
engine
which
requires
to
implement
kind
of
promises
must
have
some
type
of
microtasks
available
and
in
other
kind
of
benefits
we
say
that
finalizers
always
run
in
javascript
thread.
It's
a
nice
kind
of
added
benefit,
so
we
never
run
finalizers
in
some
random
threads.
So
we
kind
of
avoided
all
together.
This
issue
with
multi-threading
and
stuff
so
like
just
kind
of
want
to
run
this
idea
by
you
and
what
you
guys
think.
B
Actually,
actually,
it
sounds
like
a
like
a
great
idea,
because
javascript
execution
is
guaranteed
in
in
in
microtasks
right,
whereas,
whereas
we've
been
having
trouble
with
with
with
the
engine,
in
fact,
it
might
not
be
a
bad
idea
to
re-implement
finalizers
as
micro
tasks
in
v8
honestly,
because
those
things
are
guaranteed
to
run.
We
don't
have
to
worry
so
much
about
engine
shutdown,
because
the
engine
won't
shut
down
until
micro
tasks
have
run.
I
think,
if
not,
then
we
need
to.
B
A
B
B
That's
a
good
question
yeah.
I
don't
know
because
the
microtask
queue
is
not
yeah,
yeah
yeah
you're
right
I
mean
we
need
to.
We
need
to
figure
out
what
the
state
of
the
microtask
queue
is
when
the
engine
quits
right,
like
because
the
thing
is
yeah.
Okay,
let
me
think
about
that
for
a
second.
So,
basically,
okay,
so
you
need
two
things
right.
B
You
need
to
have
a
hint
from
the
engine
that
this
object
is
about
to
be
garbage,
collected
right
and
then
you
need
an
you
need
the
ability
to
run
javascript
as
part
of
the
callback
that
gets
executed
when
when,
when,
after
you've
gotten
this
hint
right
so
now,
the
simplest
implementation
is
that
the
callback
gets
executed
synchronously
with
the
callback
that
you
got
tells
you
that
the
object
can
be
garbage
collected
right
that
doesn't
work.
We
know
that
right
so
so,
then
we
have
various
solutions,
one
of
them.
B
One
of
them,
is
to
to
do
the
second
pass.
Callback
right,
the
other
one
for
buffers
for
external
buffers
is
to
to
do
a
set
immediate
right.
We
do
a
set
immediate
for
buffers,
so
I
guess
in
in
the
hermes
case.
E
You
do
in
response,
so
the
way
it's
done
like
pretty
much
any
object
has
a
special
kind
of
static
flag
during
creation.
Should
it
run
for
another
or
not
and
they
have
special.
E
If
you
like
a
host
object,
so
everything
for
they
do
they
kind
of
run
in
finalizer,
so
think
if
our
host
object
actually
referring
to
some
native
object,
so
we
can
execute
the
destructor,
but
at
this
point,
they're
saying
that
they
can
execute
our
native
destructor,
but
they
say
like
it's
garbage
called,
is
unstable
state,
so
kind
of
a
javascript
code
can
be
called
from
there.
B
Yeah
yeah
the
same
thing
happened
in
v8,
but
v8
has
this
second
pass,
but
but
hermes
doesn't
right?
Okay,
so
then
what
you
would
do
correct
me
if
I'm
wrong
is,
is
when,
when
the
when
the
finalizer,
when
when
hermes
calls
the
finalizer,
then
you
would
you
would
enqueue
a
micro
task
which
will
then
execute
the
user's
code.
Correct.
E
Right
in
almost
like
begs
the
question
like:
should
we
separate,
should
we
have
two
types
of
finalizers
like
finalizers,
which
I
kind
of
guarantee
no
javascript
execution,
which
is
safe
to
be
kind
of
executed
almost
immediately
another
one
is.
B
Yeah
we
don't,
we
don't
like
an
api,
doesn't
have
a
way
of
indicating
whether
the
finalizer
executes
javascript
or
not.
So
we
have
to
assume
for
all
of
them
that
they
do
yeah.
I
mean
okay,
one
possible
implication
of
what
you
just
said
is
that
maybe
we
want
to
add
a
flag
like
that
and
add
an
api
that,
because
we
we
have
an
api,
add
finalizer
right
which
which,
which
you
can
add
a
finalizer.
You
know,
after
the
fact
to
anything
you
want
that
accepts
finalizers.
B
Obviously,
and
we
could
add,
we
could
add,
like
an
api,
add
native
finalizer
or
something
like
that
and
then
and
then
that
would
be
the
indication
that
that
from
the
user
that
no
javascript
code
will
be
executed
and
then
maybe
we
can
do
it
differently.
B
A
B
Yeah
yeah
yeah.
Well,
not
necessarily.
If
we
have.
If
we
have
a
worker
shutting
down,
then
then
what
we
do
is
we.
We
maintain
a
list
of
all
the
references
that
we
have
right
and
then
we
we
call,
we
call
them
in
a
tight
loop
at
the
end,
the
ones
that
are
left
over
right
like
we
have
that,
and
it's
had
many
many
implications.
B
The
fact
that
we
do
that
now
just
to
clean
up
the
thread
and
so
for
hermes
yeah.
There
are
two
outstanding
questions
upon
shutdown:
does
the
microtask
queue
run
before
the
engine
shuts
down?
That's
one
of
the
questions
so
as
to
ensure
that
all
the
references
are
basically
resolved
and
finalized,
and
the
second
question
is:
will
you
always
be
able
to
to
enqueue
a
microtask
into
the?
B
Will
you
always
be
able
to
enqueue
a
microtask
like
what?
If
what,
if
the
the
the
object
like?
What,
if
hermes
informs
you
that
this
object
is
being
garbage
collected
because
the
engine
is
shutting
down
right
and
then
you
turn
around
trying
to
enqueue
the
user's
finalizer
and
only
to
find
that
the
microtest
queue
has
already
been
well
finalized
or
shut
down
or
destroyed,
or
folded
up
or
whatever,
and
then
you
can't
enqueue
a
microtask.
So
at
that
point,
do
you
do
you
immediately
call
the
user's
finalizer?
Do
you
error
out?
Do
you
ignore
it?
B
Yeah
yeah,
that's
right,
but
that's
that's
okay-ish,
because
because
whenever
a
new
reference
appears,
we
put
it
to
the
front
of
the
linked
list
and
the
way
we
destroy
all
the
references
is
that
we
keep
starting
at
the
front
and
then
destroying.
So
basically,
we
always
destroy
the
first
item
in
the
linked
list.
So
if
a
new
item
appears,
it'll
it'll
just
get
destroyed
right
away.
B
So
but
that's
that's
our
mechanism
right
for
for
for
v8,
so
I
I
don't
know
if,
if
for
hermes,
you're
gonna
need
to
have
this
tracking
that
we
have
for
v8,
because
in
v8
we
know
for
sure
that
when
the
engine
shuts
down
whatever
items
have
finalizers
will
never
have
their
finalizers
called
because
va
just
doesn't
care
they're
like
track
your
own
memory.
I
don't
care,
I'm
shutting
down.
B
E
E
I'm
not
sure
like
if
even
yeah
I'll
check
what
exactly
hermes
does
with
microtusk,
but
I've
seen
this
api
that
you
can
pop
with
pump
with
micro
task
queue
yourself.
If
you
need
to
okay,
it's
it's
probably
not
part
of
a
node
api
exposed
to
modules.
But
it's
part
of
our
node
api
will
be
to
host
engine
effectiveness
yeah
it's
because
it
will
be
host
application,
which
decides
at
some
point
to
kind
of
shut
down
the
environment.
E
And,
yes,
we
can
actually
implemented
part
of
his
environment
as
shutdown
mechanism.
B
B
Well,
it's
the
developer's
fault
for
for
for
adding
more
stuff,
you
know
because
it's
basically
an
infinite
loop.
At
that
point
you
know,
and
and
and
it
doesn't
happen
with
every
application-
it
only
happens
with
you
know,
xyz
application
and
then
you're,
like
wow
g.
You
know,
debug
your
application.
B
Yeah
yeah,
I
mean
there's
nothing
preventing
you
in
node.js
from
from
creating
a
reference
during
environment
shutdown,
you
know
and
and
then
just
adding
it
to
the
references
and
then
in
the
finalizer
callback.
For
that
reference,
creating
another
reference
and
then
so
forth.
You
can
hang
node
if,
if
you
so
choose
accidentally.
E
If
you're
good
enough
so
generally
what
I'm
hearing
this
idea
that
to
run
this
finalizers
as
a
part
of
microtasks,
is
not
it's
not
so
bad,
it's
suffocating
for
right,
okay,
and
maybe
for
as
optimization
step,
we
can
add
so-called
like
our
native
analyzers,
which
would
we
say
that
we,
we
can
run
a
soonish,
but
it
we
can
add
radio.
But
it's
so
for
me.
It's
more
important
to
have
analyzers
to
be
run.
Kinda,
reliably,
yeah,
okay,
cool!
E
I'm
glad
that,
because
it's
much
much
less
changes
on
hermes
engine
side,
because.
E
Open
to
idea
to
use
proper
analyzers,
microtasks
and
any.
E
Would
require
a
little
bit
more
careful
design
and
kind
of
discussions
and
stuff,
okay,
cool
nice.
Thank
you.
B
A
Okay,
great
well,
thanks
for
everybody's
time
and
we'll
talk
to
everybody
next
week
and
in
github
thanks.