►
From YouTube: 2021-06-04-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
So
welcome
to
the
note
api
team
meeting
for
june
4th
2021,
I
guess
before
we
get
started,
does
anybody
have
any
announcements
they'd
like
to.
A
Share,
I
guess
the
one
I'll
add
is
openjs
world
was
just
last
week
and
there
is
a
talk
in
the
youtube
playlist
for
the
openjs
foundation,
where
kevin
and
gabriel
gave
a
talk
on
the
work
that
we're
doing
so.
If
you
are
interested,
that's
something
to
check
out,
you
can
watch
whenever
you
want.
B
A
Can
look
out
for
for
that?
The
four
line
is
where
we're
going
to
continue
ongoing
development.
It
will
drop
support
for
node
10,
since
it's
now
end
of
life
and
the
previous
release
was
sort
of
like
one
last
release
so
that
you
would
get
the
you.
E
A
The
the
things
that
we've
landed
between
now
and
the
previous
3.x
release,
thanks
thanks
for
that
heads
up
and
for
doing
those
releases,
any
other
announcements.
A
A
A
A
A
D
Regardless
that
the
let's
say
the
reference
is
being
a
third
reference,
it
is
not
zero.
Let's
say
202
it's
being
released
anyway,
when
the
environment
they
are
done,
but
in
the
like,
say
the
last,
the
last
implementations
they
used
the
job,
the
job
chat
to
release
the
relationship
function,
it's
very
similar
to
c
plus
plus
destructors,
that
is
to
say,
when
a
c
plus
plus
droppers,
when
a
c
plus
plus
robust,
is
being
destroyed.
It
caused
the
not
be
threatened
function
released.
D
So
when
the
environment
teardown
happens
before
the
there's
a
function
wrapper
being
destroyed,
then
the
search
director
function,
wrappers
will
fail
to
destroy
the
actual
status
function
after
the
environment
is
being
taken.
Since
we
have
already
destroyed
the
strategy
function,
internal
representatives.
D
That
the
issue
isn't
happening
in
not
app,
not
add-on
api.
It's
because
that
we
didn't
wrap
the
search
function
with
c
c,
plus
plus
constructors
and
the
distractors.
With
the
release
functionality.
We
have
users
have
to
call
the
function,
release
manually
to
release
the
threshold
function.
D
But
others
nobody
objects
we
have
already.
I
believe
there
is
no
other
similar
representatives
that
that
can
be
mirrored
to
search
for
the
concept
of
the
same
function.
So
this
is
a
very
special
one.
B
I
have
a
general
question,
which
is
on
the
existing
api,
where
we
say
that
the
those
things
are
not
thread
safe,
they're,
not
inherently
thread
safe.
Using
the
call
and
release.
D
I
believe
the
core
problem
here
is
not
just
threat
safety,
but
it
is
the
ownership
of
the
threats
function
itself,
since
we
are
going
to
destroy
any
resource
related
to
the
environment,
like
say
the
relative
function,
but
the
users
like
say
in
the
last
neon
bindings.
They
are
binding.
The
first
function
to
their
last
representatives
like
say
they
are
going
to
release
the
selection
function
regardless.
D
If
the
not
just
code
is
the
environment
is
already
been
data,
so
when
their
rust
bindings
are
being
like,
say
because
out
of
scope,
they
will
call
their
cell
function
relief.
So
that's
the
ownership
problem
of
the
third
function.
D
Calling
release
on
something
which,
after
the
environment
you've
been
it's
been
tied
down,
since
they
are
believe
that
that
is
the
same
function
if
they
are,
the
ownership
of
their
function
is,
is
on
their
side.
So
right.
But,
however,
when
the
environment
is
narrowed
down,
the
notochord
have
already
destroyed
the
test
function
and
according
the
final
penalizers,
so
they
have
to
implement,
let's
say
new
text
to
prevent
the
rust
wrappers
to
destroy
the
function
again
right.
C
A
B
B
Okay,
because,
if
we're
looking,
there
was
the
link
for
744
in
this
issue
somewhere,
if
we
can
scroll
up
or
down
it's
the
neon
bindings,
that's.
B
So
this
is,
I
guess,
their
main
complaint
here.
Is
that
the
end
when
the
environment
cleans
up
the
finalized
call
happens
and
they're
also
saying
that
they
don't
need
to
to
close
it?
If
you
make
a
call-
and
you
return
an
api
closing
like
from
everything
that
I'm
reading
here
to
me,
it
doesn't
I
I
I
personally
don't
see
a
problem,
but
maybe
I'm
just
not
seeing
it.
You
know
like
for
me
like
what
happens
if
you
have
multiple
threads
running
like
you,
have
a
thread
safe
function
and
it
has
a
counter
of
two.
B
G
My
understanding
is,
that
is
that,
because
we
have
the
the
environment
tearing
down
right,
the
the
finalize
is
is
is
added
to
the
list
of
finalizers
right,
and
so
so,
when
the
environment
tears
down,
the
list
of
finalizers
gets
called
sort
of
unconditionally
right.
G
Whether
or
not
the
threat
say
function
has
reached
a
zero
count
right,
and
so
so
in
a
way
you
know
it's
yet
it's
yet
an
other
avenue
by
which
you
abort
the
threat
say
function
like
normally
you
abort
the
threat
say
function
from
the
main
thread
at
the
action
of
javascript.
G
Ultimately
right
so
the
you
know,
user
clicks
a
button
and
then
ultimately
you
end
up
saying
abort,
and
then
you
wait
for
all
the
threads
to
close
and
everything's
hunky-dory
right
and
then
and
then
the
finalizer
happens
right
and
the
finalizer,
if
I'm
not
mistaken,
gets
called
like
synchronously.
G
After
all,
the
handles
all
the
uv
handles
are
closed,
but
but
this
is
sort
of
turning
things
upside
down
right,
because
you're
calling
the
finalizer
first,
and
so
so
you
know,
that's
that's
not
exactly
how
this
was
supposed
to
work
right,
and
so
so
you
know
in
a
way.
We
would
expect
folks
that
use
a
threat,
safe
function
to
coordinate
the
tear
down
of
the
environment
and
I'm
not
sure
how
much
we
can
support
them
in
that
and
honestly,
no
matter
what
api
we
come
up
with.
G
That's
simpler,
it's
still
going
to
run
into
an
issue
where
okay,
oh
you
want
me
to
tear
down,
but
there
are
still
threads
out
there
using
me.
You
know,
like
you
know,
I
guess
what
they're
saying
is
that
when
this
happens,
then
we
should
kind
of
let
the
environment
tear
down
but
keep
the
threat
safe
function
alive
and
consider
it
aborted.
So,
basically,
if
the
finalizer
happens,
while
while
there
are
still
outstanding
references,
then
basically
just
pretend
somebody
called
abort.
G
A
A
To
know
I
was
thinking
more
just
for
like
when
the
environment,
so
forgetting
you
know,
thread
safe
functions
or
or
anything
just
when
an
environment
starts
to
tear
down
the
add-on
should
be
able
to
register
a
function
that
says:
okay,
I'm
gonna
the
environment's
about
to
tear
down.
I
want
to
do
all
the
cleanup
in
advance
that
I
need
to
do.
A
Options
right
so
so
I'm
I'm
just
wondering,
isn't
that
the
right
solution
is
for
them
to
register
a
hook
which
says
okay,
environment
teardown's
about
to
happen.
G
Yeah
yeah,
the
problem
may
be
that
in
this
case
there
are
multiple
threads
involved
right,
and
so
you
kind
of
want
to
make
sure
or
I'm
not
sure
if
you
need
to,
but
you
may
need
to
make
sure
that
that
the
threats
have
all
terminated
before
returning.
So
that's
what
that's?
What
I
mean
by
synchronous
like
you,
do
not
want
the
environment.
A
G
G
Yeah,
I'm
not
100
sure,
like
I,
it's
been
a
while,
since
I
looked,
I
looked
deeply
at
threat
safe
function,
but
but
yeah.
So
I
I.
I
could
probably
write
a
unit
test
that
just
you
know,
launches
three
threads
and
and
they
keep
communicating
over
the
threats
they
function
and
they
they
are
in.
They
are
made
in
such
a
way
that
they
never
close.
Unless
there's
an
environment
tear
down
right
in
which.
F
A
A
G
B
Okay
and
then
I
have
another
question
regarding
the
order
of
the
finalizers,
would
the
finalizer
for
the
thread
save
function
be
called
before
or
after
the
finalizer
for
the
environment.
G
Yeah
exactly
yeah,
so
if
you
attach
a
finalizer,
you
have
no
guarantee
that
it's
gonna
get
called
before
the
one
for
the
threat
say
function
right
like
normally.
I
think
it
would,
but
I'm
not
100
sure,
there's
a
lot.
B
Them
needing
to
do
a
workaround
in
the
finalizer
would
they
need
to
be
doing
a
workaround
in
both
of
the
finalizers
in
this
environment
cleanup
one
to
see
if
this
one
runs.
First
now
we
have
to
clean
up
the
threads
there,
or
also
in
the
thread
safe
finalizer.
If
that
one
gets
called
first,
because
the
environment
is
shutting
down
and
it's
been,
the
tssn
has
been
unwrapped.
G
G
Yeah
yeah
yeah,
yeah
yeah,
and
that
that
tells
me
the
fact
that
they
need
to
use.
So
I
I'm
guessing
that
basically
they're
they're
telling
they
have
to
tell
their
threads
okay
shut
down
now,
because
the
thread
safe
function
is
going
down
right.
So
so
what
that
means
is
that
the
mechanism
whereby
the
the
the
call
returns
closing
isn't
working
for
them,
because
the
finalizer
is
happening
so
soon,
and
so
they
need
to.
They
need
to
basically
tell
them
hey
closing
right
from
the
finalizer.
G
So
so
that's
why?
I'm
thinking
that
the
solution
to
this
is
quite
simply
to
to
mark
the
threats
they
function
as
in
the
process
of
closing,
if
the
finalizer
gets
called
because
normally
the
threat
say
function
is
responsible
for
calling
the
finalizer
of
when
when,
when
somebody
calls
release
and
the
account
drops
to
zero.
A
I
think
the
finalizer
is
too
late
because
as
soon
as
the
finalizer
runs,
I
think
right
after
that,
the
object
that
you
know
everything
should
be
gone
by
then
right,
like
the
this
yeah,
the
handle
that
you
have
for
it
is
invalid.
After
that's
complete,
I
think.
G
Yeah
yeah
yeah,
yeah
yeah,
so
so
yeah,
so
okay.
So
under
these
special
circumstances
the
finalizer
would
have
to
basically
hang
on
until
all
the
threads
have
reported
in
and
released
the
thing
so
so
that
would
that
would
be.
That
would
basically
be
like
a
busy
loop
inside
the
finalizer
mutually
exclusively
checking
the
ref
count
until
it
drops
to
zero.
A
G
Well,
okay,
but
I'm
not
talking
about
the
finalizer
we
already
have,
which
is
the
finalizer
for
the
threadsafe
function
right.
So
in
that
finalizer
we
place
this
busy
loop
right,
not
in
some
kind
of
environment,
cleanup
hook
that
that
that
somebody
else
provides
right.
So
basically,
what
I'm
saying
is
the
finalizer
will
not
return
until
the
the
the
threat
say:
function's
own
finalizer
will
not
return
until
all
the
threads
have
quit
right
and
and
release
the
threat
safe
function
because
and.
G
B
The
main
concern
is,
if
you
call
unref
on
the
tsfn,
which
then
would
allow
the
environment
to
shut
down,
even
if
the
counter
is
above
zero.
Is
that
that's
the
main
issue
here
so
yeah?
I
think
that's
what
legendarcast
had
mentioned
at
the
very
beginning.
G
F
G
Okay,
all
right,
so
all
right
so
now
now
the
picture
is
becoming
clear
because
I
kind
of
missed
the
beginning.
Okay,
so
so
so
so
this
is
under.
The
the
whole
thing
is
under
the
unrefined
case,
right
where,
where
it's
it's
not
supposed
to
prevent
event,
loop
exit,
so
all
right.
So
let
me
see
if
I,
if
I
can
summarize
this,
if
the
thread
say
function
is
set
to
not
prevent
main
loop
exit,
then
upon
finalization,
it
leaks,
correct.
D
G
B
See
but
my
thought
is
like
if
you
are
calling
unref,
then
you
as
the
programmer.
The
developer
need
to
be
aware
that
if
the
event
loop
has
nothing
on
it,
except
your
thread
safe
functions,
it's
possible
for
everything
to
shut
down
when
you're
not
expecting
it,
and
you
just
have
to
be
aware
with
your
threads
like
yes,.
G
That's
true,
that's
true.
However
it
it
can
be
considered
that
it
can't
be
considered
expected
behavior
for
there
to
be
an
implicit
call
to
abort
when
this
happens,
because
the
finalizer
does
get
called
right,
so
so
so
so
so
so
that
pathway
is
initiated.
It's
just
not
doing
the
right
thing
right.
That's
you
know
what
I
mean.
So
I
think
that's
that's
sort
of
the
the
bug
angle
of
it.
You
know.
A
G
Problems
smaller,
the
the
I
I
think
the
question
is
this:
in
our
finalizer
after
we
have
called
yeah
so
okay,
so
the
the
finalizer
for
the
threat
say
function
is
expected
to
wait
on
all
the
threads
like
join
all
the
threads
right
if
they
need
joining.
If,
if
you
have
the
kind
of
a
threading
implementation
where
threads
need
to
be
joined
at
the
end,
otherwise
they
leak
right.
That
may
or
may
not
be
the
case
right.
G
If
it
is
the
case,
then
the
finalizer
then
calling
the
user's
finalizer
from
our
finalizer
should
ensure
that,
by
the
time
that
user's
finalizer
returns,
the
the
ref
count
will
be
zero
unless
the
threading
implementation
is
incorrect
right
now,
if
the
threads
do
not
need
to
be
joined,
then
then
we
call
the
users
finalizer
and
afterwards
we
have
to
wait
visibly
synchronously
until
the
ref
count
drops
to
zero,
and
then
we
can
proceed
with
with
with
just
like
freeing
the
the
threats
they
function
structure.
It.
A
G
But
wait
a
second
when
we
called
the
when
we
called
when
we
entered
the
finalizer,
the
threat
say
function
is
still
allocated
right.
So
so
then
so
then
you
know
we
can.
We
can
simply
do
what
I
just
said
right
and
and
then
just
not
use
the
threat
say
function
after
we
are
done,
calling
the
user's
finalizer
right
just
return.
D
G
Yeah,
I
think
I
I
think,
yeah
yeah.
I
think
I
think
that
the
c
plus
plus
wrappers
are
a
completely
different
issue
like
if
this
is
happening
in
core
and
it
needs
to
be
fixed
in
court
and
we
should
fix
it
in
core
and
then
when
we
know
that
core
is
working
correctly,
we'll
see
what
the
implications
are
for
know
that
on
api,
but
either.
F
D
I
mean
we
are.
We
can
call
in
the
now
because
the
function
released
in
our
not
an
api,
that's
a
function
destructors.
We,
we
didn't
recall,
releasing
our
destructors
in
node,
add-on.
Api.
I've
checked
that.
So
that's
the
problem
that
we
didn't
binding,
find
the
c
plus
plus
object
lifetime.
With
the
the
plain
c
pack,
you
object.
D
B
B
D
D
A
We've
spent
quite
a
bit
of
time.
Is
it
okay
to
move
on
to
other
things
and
continue
that
on
through
github
yeah.
B
I
think
so
there
was
one
stale
issue
that
I
just
added
to
the
stale
issues
list,
because
I
think
it
was
something
that
we
did
talk
about
regarding
assuming
that
errors
that
you're
throwing
are
objects.
A
D
E
A
D
G
A
A
A
A
A
A
D
There
is
a
there
is
two
things
that
needs
to
be
cleared
to
be.
No,
no
pointer
is
that
the
first
is
the
second
pass
parameter
for
the
reference
we
have.
That's
that's
the
member
of
the
reference
and
the
other
one
is
the
content
of
the
second
pass
parameter
right.
D
A
D
Yeah,
that's
the
problem.
The
finalize
the
finale
is
being
called
in.
The
second
pass
go
back,
so
we
are
calling
clear
week
in
the
second
pass
callback
it
it's
a
bit
too
late,
since
we
since
when
the
second
pass
callback
is
being
invoked,
it
might
be
after
the
environment,
environment
is
tear
down
and
after
the
actual
reference
structure
is
being
destroyed.
D
A
A
A
That
seems
to
have
been
fixed
by
this
as
well
so
cool,
even
though
we
we
didn't
get
the
crash
in
on
linux,
and
it
only
happened
on
osx.
For
some
reason,
it
seems
like
this
fix
fixes
that
too.
A
Yeah
definitely,
okay,
so
yeah.
If
you
can
comment
on
that
and
it's
it
makes
sense
gabriel.
If
you
want
to
take
a
look
too,
that
would
be
or
anybody
else
take
a
look
as
as
as
we
found.
This
is
a
really
tricky
area.
I'm
hoping
this
will
be
the
last
one
for
now,
based
on
the
valgrind
results,
but
who
knows
okay,
so
going
back
to
milestone
11
then,
are
there
any
other
issues
that
there.
B
Is
an
issue
that
I
would
like
to
discuss
in
node
add-on,
api?
Okay,
it's
the
most
recent
issue.
B
And
I
was
able
to
replicate
it,
so
I
don't
know
it's
a
compiler
oddity
using
gcc
11
with
c
plus
20
enabled
gives
you
these
errors
on
the
typed
thread.
B
Safe
function,
using
a
different
compiler
like
the
mac
os
x,
c
lang
on
c
plus
plus
20
does
work
using
gcc
11
with
a
lower
c
plus
version
like
17
does
work,
and
I
think
he
also
said
I
did
not
check
this,
but
he
said
if
we
scroll
down
a
bit
using
gcc
10
with
c
plus
plus
20
does
work
so
increasing
gcc
from
10
to
11
breaks
when
using
c
plus
12
20.
B
B
B
F
A
A
A
B
A
A
Okay,
any
others
that
people
had
on
the
top
of
their
mind
to
discuss.
D
D
A
Okay,
that
sounds
good,
any
others
that
people
want
to
bring
up.
B
I
will
just
say
now,
since
there's
a
little
time
left
the
the
conference.
I
had
the
q
a
session
yesterday
and
no
one
had
any
questions,
so
I
don't
know.
A
B
E
A
So
we
may
have
closed
it
once
it
was
recorded
right.
So
this
talk
so.
A
F
A
Sounds
good
and
then
vladimir,
I
kind
of
want
to
ask
you
the
same
thing
as
well.