►
From YouTube: Node.js Node-API Team Meeting 2021-03-05
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
unless
there
are
any
announcements
to
make,
please
make
them
now,
if
you
have
them
otherwise
we're
going
to
get
started
with
the
agenda
so
going
once
going
twice
gone
all
right
agenda
that
is
so
then
screen
sharing
is
about
to
start
somehow
geez.
This
thing
has
changed.
A
A
Okay,
good
all
right
so
renaming
an
api.
Let
me
see
what
has
been
going
there.
We've
done.
I
think
tests
and
docs
and
jim
I
I
saw
you
did
something
on
api,
stable,
node
you
having
had
the
last
commit
there.
So,
let's
see
what
else
is
missing?
It's
a
good
checklist.
Let's
see!
No,
so
you,
you
didn't
know
jip
as
well.
Eh.
C
Okay,
so
yeah,
I
just
need
to
get
out
to
those
other
projects.
The
other
thing
I
noticed
is
I
I
don't
know
how
it
happened,
but
the
the
node
api
resource,
the
the
tutorial
site,
did
not
get
updated.
So
I
that
that
is
next
on
my
list.
A
Okay,
all
right
sounds
good
okey-dokey.
So
then,
let's
see
here,
okay,
blog
post
about
transition
to
node
api;
okay,
all
right,
okay.
So
so
I
guess
we're
working
on
this.
Do
we
have
like
a
google
doc
for
this?
Not
yet.
B
I
I
I
will
send
only
to
the
team,
a
member
and
and
maybe
after
we
will
may
make
public
all
the
content.
B
A
All
right
so
so
there
we
go.
We
got
the
article
going
all
right,
stale
issues,
all
right,
let's
see
see
here,
let's
see.
Oh
sorry,
I'm
still
getting
used
to
this
computer
all
right.
So
these
these
three
are
new,
well
new
ones
to
discuss.
So
let's
go
for
the
first
one.
B
I
I
I'm
working
on
on
this,
but
I
did
not
and
to.
A
Oh
wait
a
minute:
oh
yeah,
we
don't
have
a
finalizer
is
that
is
that
the
problem
is
that
is
that
these
these.
B
I
saw
on
the
note
the
core
label,
and
in
this
case
we
don't
call
a
finalizer.
No,
if
you
just
created
the
buffer
using
nappy,
underscore
create
external
buffer
and
yeah,
and
we
never
called
the
final
order
so
yeah
we
never
released
the
the.
A
So,
okay,
so
wait
a
minute.
Let
me
see
if
I
understand
this
correctly,
so
the
so
so
the
the
core
api
doesn't
call
the
file
analyzer
or
node
add-on
or
the
core
api
calls.
The
know
that
on
api
finalizer,
but
the
node
api
finalizer
doesn't
call
the
user's
finalizer
is
that
which
one
is
it?
Is
it
the
first
thing
I
said
or
the
second
thing
I
said,
the
problem.
A
So,
okay,
let
me
let
me
try
to
rephrase
yeah.
Does
the
core
part
of
it.
B
D
A
B
Yeah
yeah:
this
is
the
problem
because
yeah
we
okay,
if
you
provide
the
final
rights,
cd
yeah,
the
the
finalizer,
will
be
called
and
you
can
release
the
and
destroy
the
the
data.
If
you
want
to
know.
E
B
But
in
when
you.
B
Oh
boy,
yeah,
we
don't
provide
the
us
finalizer
yeah
identifying,
so
that
a
call
no
is
to
to
to
raise
the
ladder,
and
this
is
this
is
the
problem
for
me.
B
A
Well,
I
don't
think
we
should,
because
you
know
you
don't
know
what
mechanism
was
used
to
allocate
you
know.
Was
it
malloc?
Was
it
map?
You
know
what
what
what
was
the
mechanism
right?
So
so
you
don't
want
to
like
call
free
or
delete
right,
because
who
knows
whether
that
does
the
right
thing
you
know,
but
because
yeah,
because.
B
I
don't
know
who
use
uses
that
data
and,
if
yeah,
and
how
so
so,
yeah
the
implementation
that
we
provide.
It
could
be
okay,
but
we
need
to
document
like
minimum.
No,
these
be
obvious.
A
B
Maybe
maybe
maybe
developers
could
think
that
okay,
they
provide
a
default
finalizer
that
delete
the
data
for
for
us.
So
I
see
yeah.
This
is
the
problem.
A
B
A
Oh,
I
see
okay,
okay,
so
we
have
these
and
then
here,
okay!
So
there's
this
one
and
this
one
right,
yeah,
okay!
Well,
this
one
here
this
one
here
is
our
under
this
one
here
is
under
our
control
right,
because
this
creates
a
new
buffer,
but
this
is
not
under
our
control
right.
This
is
data
coming
in
from
the
user,
and
so
here
we
have
to
say
that
that
this
data
will
not
be
free
right.
A
So
here
basically
like
here,
maybe
like
between
these
two,
like
ad,
I
had
a
warning
saying,
like
you
know
this
this,
this
data
will,
you
know,
will
will
not
be
freed
if,
if
like,
if
you
wish,
if
you
wish
to
be
informed-
that
that
this
buffer
will
be
destroyed
and
you
and
you
wish
to
free
the
data
at
that
time,
then
don't
use
this
method.
Use
this
method
here
right
or
this
one.
A
B
Yeah,
I
I
I
can
work
on
this
and
yeah
I
I
will
add
this
on
on
the
buffer
and
array
path
for
documentation,
because
on
drive
and
on
the
right
on
the
right
buffer.
We
have
the
same
problem.
B
A
There
we
go
okay,
understood,
okay,
so
yeah.
That's
it's
a
good!
It's
good
to
point
that
out:
okay,
so
that
was
this
guy
and
then
830,
oh,
the
iterator,
okay
right!
So
what
what
have
we
been
got
with
this
canon?
And
it
seems
reasonable-
might
be
youtube,
sparse,
race,
etc?
Okay,
yeah,
okay,
so
this
one
is
status
quo
because
the
person
has
not
yet
reacted
to
michael's
question.
A
Yeah,
I
I
don't
know
if
we
can
make
any
progress
with
this
yeah
yeah
they
haven't
reacted.
I
guess
these
two
folks
they're
not
really
involved
with
with
v8
anymore,
or
at
least
not
this
portion
of
v8
yeah.
I
don't.
I
don't
know
if
this
is
ever
going
to
happen
like
it's
basically
up
to
v8
to
to
to
provide
a
way
to
do
this.
Otherwise
it's
it's
very,
very
hacky
and
and
and
yeah.
There
are
just
some
fundamental
issues
with
this.
A
A
A
All
right,
yeah,
okay,
so
then
we
return
to
the
milestone.
Okay,
so
tracking
issues
wait,
yeah
that
was
tracking
issues
for
module,
okay
and
and
okay,
no
news
here,
but
this
is
the
time
to
check
mpmjs.com
package
api
and
see
where
we're
at
hot
diggity
dog
we're
almost
to
4
million
well
well.
Well,.
A
Cool
all
right:
well,
maybe
next
week,
yeah
okay,
this
is
good
all
right.
So,
having
recorded
that,
let's
move
to
external
examples,
I'm
afraid
that's
a
status
quo,
but
I
think
I
think
the
pr
got
merged
right.
So
it
is
where
it
is
and-
and
we
can
always
fix
it
up-
and
I
mean
it
seems
like
it's
seems
like
you
know,
it's
an
active
repo.
So
you
know
if
there
are
issues
with
it,
they
may
come
to
our
attention
all
right.
Let's
see
enable
debug
testing
yeah.
A
I
don't
know
if
michael
had
any
chance
to
work
on
this,
otherwise
it's
status
quo
and
then
module
owners.
Okay,
so
those
were
new
issues.
Now,
let's
look
at
are
those
were
old
issues
now,
let's
look
at
new
issues,
so
github.
A
Okay,
is
it
possible
to
store
buffers
without
copying
and
confusion,
about
instance,
data
handling
ll
instance,
data
currently
trying
to
build
an
add-on
using
node.on,
api
or
sorry
yeah
on,
however,
completely
about
the
idea
behind
settings.
D
D
D
A
A
All
right
there
we
go
close
with
comments.
A
All
right,
good
yeah,
that's
great
yeah
people
are
using
these
things.
All
right
see.
Let's
see
here
templated
class
instance
based
on
js
constructor,
oh
yeah,
I
don't
know
if
you
can
do
that
right
with
different
types
depending
on
user
input,
something
like
this:
okay,
okay,
yeah!
That's
I
don't
know
if
you
can
do
that.
A
Yeah
yeah
yeah
exactly,
but
the
problem
is
that
that
c,
plus
plus
templates
are,
are
instantiated
at
compile
time
right,
yeah,
so
yeah
at
compile
time.
You
cannot
know
what
value
would
be
coming
in
at
runtime.
So
basically
you'd
have
to
do
a
switch.
You
know
like.
If
is
is
date,
then
they,
if
is
right,
so
yeah,
there's
no
way
to
to
to
do
this.
D
Time,
the
only
solution
is
to
gauge
what
kinds
of
types
may
arrive
into
the
constructor
and.
D
B
D
B
B
Maybe
you
can
use
number
no,
his
number
so
okay,
see.
A
A
A
A
D
A
D
A
A
Yeah
yeah
all
right!
So,
let's
see
here:
okay,
that's
the
okay:
how
to
pass
a
callback
to
an
object,
rapper
to
be
executed.
Async.
D
C
D
D
A
A
A
B
B
No,
I
yeah
it's
a.
This
is
another
issue.
A
A
A
A
A
A
A
Well
well:
well,
yes,.
A
A
Okay,
okay,
this
is
yours,
getting
clear
assumes:
yes,
that's
right:
it
does
yeah
yeah
yeah
yeah.
I
think
I
posted
yeah
to
a
link
to
this
issue
here.
So
so
that's
that's!
Basically
why
we
we
do
this.
Is
that
yeah?
So
so
there
are
two
issues
here.
First
of
all,
we
need
to
the
whatever
it
is
that
you
throw
has
to
be
a
reference,
because
because,
let's
say
you
you,
you
have
a
call
and
inside
the
call
you
do
your
handle
scope
in
there.
A
The
error
is
a
is
a
c
plus
exception
right,
and
so
so
the
so
the
c
plus
plus
exception
will
cause
the
frame
in
which
it
was
thrown
to
be
destroyed
right,
but
when
the
frame
is
destroyed,
the
handle
scope
is
closed,
and
so
the
so
the
value
you
created
in
that
frame
is
is,
is
also
destroyed,
right
and
so
so
so
then
is
destroyed
by
the
engine,
not
not
by
the
not
by
the
language
right
and
so
so,
then
you
cannot
put
it
back
into
javascript
unless
it's
a
persistent
reference
now.
A
The
second
problem
is
that
we
decided
early
on
in
napi
that
persistent
references
can
only
be
made
to
objects.
We
cannot
have
persistent
references
to
to
like
a
string
or
or
a
number.
It's
it's
an
interesting
limitation.
It's
certainly
not
a
problem
with
with
at
least
v8
and
jerryscript.
I
know
both
of
them
can
have
persistent
references
to
primitive
values,
but
I
suspect
that
the
reason
we
limited
it
is
because
some
engines
couldn't
they.
A
A
If,
if
you
want
to
spend
some
time
trying
to
trying
to
maybe
explore
that-
or
maybe
I
can,
if
I
can
find
a
time
which
is
which
is
to
you
know
when,
when
you
attempt
to
construct
an
error
using
using
a
primitive
value
right,
then
you
construct
an
object,
but
you
somehow
mark
the
object
in
such
a
way
that
you
know
when
you,
when
you
throw
the
error
into
javascript.
A
You
know
that
oh,
this
is
like
a
special
kind
of
object,
and
so,
instead
of
instead
of
throwing
the
object
itself,
you
throw
like
one
of
the
properties
of
the
object
back
into
javascript,
and
so
it's
kind
of
a
workaround.
I'm
not
sure
if
it's
possible
to
do
it
cleanly.
A
But
this
is
one
way
we
might
be
able
to
handle,
throwing
you
know
just
any
any
sort
of
primitive
value,
but
I
haven't.
I
haven't
had
any
chance
to
to
try
to
explore
that,
and
so
then
you
know
so
you
have
an
object
with
the
property
and
the
property
is
really
the
thing
you're
interested
in.
E
Actually
we
have,
we
have
been
using.
We
have
been
seeing
a
similar
case
in
javascript.
You
know
that
in
javascript
the
primitive
values
are
like
numbers.
E
Small
numbers
are
encoded
into
the
into
the
value
pointer
directly,
so
in
that
case
there
is
a
click
on
that
the
value
zero
is
treated
as
a
you
see
in
node
api.
If
you
return
a
now
in
a
in
a
cpr
ec
plus
plus
function
to
javascript
you'll
get
a
actually
a
now
in
javascript
right
and
in
that
case
the
javascript
in
javascript.
The
zero,
as
now
in
javascript,
means
the
primitive
number
zero.
E
So
if
we
have
to
keep
consistent
behavior
between
the
node
and
the
javascript
node
api
implementation,
we
have
to
drop
every
every
zero,
or
maybe
some
other
case
to
present
that
it
is
a
0
or
it
is
a
no.
E
C
E
To
the
object-
and
we
have
we
have-
maybe
some
like
say
throwing
it
so
there
are
too
many
cases
we
have
to
wrap
around
it,
so
the
overhead
might
be
unacceptable
in
the
case,
so
there
are
too
many
drops
and
unwraps
around
the
value.
So
I
I
am
very.
A
Yeah
yeah
yeah
yeah.
That's
that
that's
a
good
point.
However,
one
one
thing
that
I
can
think
of
is
that
since
we're
talking
about
errors
right,
you
know
if,
if
you're
in
a
situation
where
you're
throwing
many
many
many
many
many
many
errors
very,
very
in
a
very
tight
loop,
then
that's
maybe
not
a
good
way
to
run
a
program
right.
A
So
I
guess
what
I'm
trying
to
say
is
if
you're
about
to
throw
an
error
you're
already
in
an
exceptional
situation
right
and
so
so
now,
you're
saying
that
okay,
I
have
to
throw
an
error
and
I
have
to
rap
and
I
have
to
unwrap
right
and
so
so
you're
saying
that
may
be
unacceptable,
but
that's
only
unacceptable
if
you,
if
you
do
this
a
lot,
whereas
you
know
the
fact
that
you're
throwing
an
error
should
mean
that
you
know
the
program
is
about
to
end
right
like
but
then
of
course,
you're
right.
A
It
depends
on
the
use
case.
I'm
just
saying
that
you
know
if
you:
if
we
did
this
in
a
like
an
object,
wrap
constructor,
then
I
would
understand
that
you
don't
want
to
do
an
extra
wrap,
but
since
this
is
an
error
case,
you
know,
is
it
really?
Is
it
really
that
bad
like
do
you?
Do
you
have
a
situation
where
you
have
to
throw
like
a
hundred
thousand
errors
per
second,
you
know.
If
you
do
then
you're
absolutely
right
and
it's
not
worth
doing
the
wrapping.
A
E
I'm
still
hesitant
about
the
statement
on
the
exception
case,
since
exceptions
in
javascript
are
very
common
code
that
we
may
be
wrong
so
yeah
in
javascript.
Those
exceptions
are
not
fatal
errors.
Those
programs
are
expected
to
continue
to
run
on
the
exceptions.
So
we
are.
E
We
may
not
assume
that,
once
the
exception
was
thrown,
the
program
is
expected
to
run
a
very
strange
condition,
so
I'm
still
hesitant
on
adding
much
overhead
to
the
quad
path
in
throwing
pass
so
and
and
the
node
add-on
api
is
the
very
low
basic
packages
to
native
add-on
developers,
so
the
the
magic
added
to
node
add-on
api
may
be
very
hard
to
use.
You
see
harder
to
understand
to
those
native
add-on
developers.
E
A
Yeah,
absolutely
that's!
You
are
absolutely
correct,
yeah.
In
fact,
in
fact,
we
should
probably
we
should
probably
encourage
add-on
developers
to
throw
proper
errors
right,
like
objects
of
javascript
type
error,
because
that
is
that
is
good
practice
right
and
so
so
yeah.
We
should
yeah,
because
I
know
I
know
in
pure
javascript
world.
It
is
also
discouraged
to
throw
things
that
are
not
error,
objects.
You
know,
throw
strings
and.
A
It's
it's
discouraged
so
so
yeah.
If
we,
you
know
we,
we
can
simply
come
down
saying
that.
Yes,
sorry,
we
don't
support
that,
because
it's
bad
practice
anyway,
and
so
you
know-
and-
and
you
could
you
know
if,
if,
if
add-on
developers
want
this,
they
can
definitely
add
it
themselves
right
like
if
they
want
to
go
so
far,
they
can
right.
They
can
do
this
wrapping
themselves.
We
don't
need
to
do
it.
You
know
they
can
throw
they.
They
can
throw
us,
they
can
throw
a
string,
they
can.
A
They
can
write
their
own
utility
for
for
throwing
things.
You
know
which
does
the
wrapping.
So
you
know
if
they
absolutely
totally
completely
unequivocally
need
this,
then
we
can
help
them
out
by
you
know
here:
here's
here's,
a
here's,
a
utility
that
you
can
write.
That
does
this
for
you
and
then
you
have
to
change
your
binding
to
to
put
everything
inside
the
try
block
and
then
you
know
and
then
and
then
throw
throw,
throw
just
a
regular
value.
A
You
know,
or
or
even
just
just
write
like
a
javascript
function
which
is
written
in
pure
javascript,
which
you
pass
in
and
then
you
pass
in
the
value
and
then
the
function
throws
you
know
it.
It's
so
basically
wrap
wrap
like
like
a
javascript,
throw
statement
into
a
function,
pass
the
function
to
your
native
library
and
then
you
can
throw
whatever
you
want.
You
know,
so
there
are
solutions
if
they
absolutely
need
it
right,
but
but
by
default
we
are
discouraging
this.
E
You
know
there
might
be,
the
crash
might
still
be
unexpected.
You
know
the
there
might
be
cases
that
I'm
still.
A
A
Where
is
this
yeah
yeah?
We
should
document
we.
We
may
need
to
update
the
documentation
that
you
know
you
can't
just
throw
anything.
You
want:
okay,
okay,
so
there
dark-
and
I
think
this
error.
E
A
Okay,
so
we
have
this,
throw
as
javascript
exception,
right,
yeah
but
yeah,
so
so
we're
kind
of
forcing
it
a
little
bit
here
right
because
because
we're
we're
making
this
we're,
making
this
like
an
instance
method
on
error
right,
which
means
you
have
to
have
constructed
an
error
in
order
to
throw
anything,
but
in
in
in
pure
an
api
in
the
c
library
we
have,
you
can
throw
any
an
api
value
right
so
so
this
is
an
artificial
restriction.
E
A
Yeah,
that's
a
good
point
right
yeah,
and
then
it
tries
to
do
that
as
an
error.
Okay,
okay,
I
see,
I
see
what
you're
getting
where
you're
going
with
this.
So
so
then,
so
then
correct
me.
If
I'm
wrong,
we
need
to
we.
We
may
want
to
change,
get
and
clear
exception
to
return
just
a
plain
value
right.
So
so,
instead
of
returning
an
an
api
call
and
call
an
error,
we
may
want
it
to
return
like
an
api
colon
colon
value.
A
If
c
plus
exceptions
are
turned
off
right.
E
A
Okay,
yeah
yeah:
do
you
think
you
can
do
a
pr
with
that
and
then.
E
I
may
find
any
time
to
do
that.
Okay,
I
would
like
to
test
it
if
it's
so
most
of
the
case,
if
the
zipper
plus
exceptions
are
disabled.
D
A
A
A
Yeah
all
right:
okay,
since
we
only
have
five
minutes
left
I'd
like
to
talk
about
one
issue
in
core,
which
is,
I
forget,
what
the
issue
is,
but
you
you
brought
it
up,
you
have
a
repro
for
it.
Do
you
remember
the
issue
number,
but
in
case
you
don't
because
I
have
a
solution
for
that
issues.
A
Right,
yeah,
okay,
so
so
there
there
is.
There
is
a
solution.
One
thing
we
forget
to
do
during
during
the
environment:
teardown
is
to
to
clear
weak.
So
we
in
a
way
during
environment,
tear
down
we're
saying
we
are
responsible
and
api
is
responsible
for
for
for
running
the
finalizer.
So
you
know
javascript
engine
stay
out
stay
out
of
my
way.
I
am
going
to
do
all
the
finalizing
right
but
yeah,
but
in
order
to
do
that,
we
have
to
clear
weak
right.
E
A
A
C
A
Under
normal
circumstances,
the
garbage
collector
will
never
run
during
the
finalize
all
loop,
because
the
finalize
all
loop
is
running
so
so
the
garbage
collector
cannot
run
right
because
control
is
inside
the
loop.
That
says,
you
know
finalize
reference
finalize
reference
finalize
it.
What
is
it
for
the.
E
Familiarities
called
javascript
and
the
javascript
reached
a
a
case
that
triggered
a
garbage
collection.
A
Yes,
yes,
exactly
exactly!
Thank
you,
okay!
So
let
me
see
if
I
understand
this
correctly
in
your
reproduction,
you
call
gc
explicitly
right
but
yeah.
If
I
understand
correctly,
what
you're
saying
is
that
if
you
call
any
kind
of
javascript
whatever
you
know,
not
necessarily
gc,
then
a
gc
can
be
triggered
and
a
gc
can
run
before
that
call
to
javascript
returns.
Is
that
what
you're
saying?
Is
that
correct?
Okay?
I
see
I
understand
okay,
so
then
so
then
we
need
the
solution
right
and
yes,
but
we
don't.
A
E
Some
simple
look
around
for
this
like
say:
we
can
run
force
the
gc
to
be
wrong
on
the
process
exit
event,
so
the
weak
finalizers
are
definitely
to
be
connected
to
on
the
next
event.
So
that's
a
simple
workaround
for
the
issue,
so
there
is
no
has
no
rush
to
resolve
the
problem.
Since
the
problem.
C
E
Only
to
be
crash
on
there
are
chance
to
crash
on
the
tear
down
even
tell
them.
A
Okay,
okay,
so
you
found
a
workaround
okay,
that
that's
good,
but
we
should.
I
think
we
should
still
we
should
still
do.
Let
me
show
you
what
cd
dot
dot?
Slash
node,
get
branch:
okay,
get
diff,
okay,
so
this
is
what
I'm.
This
is
what
I'm
thinking
this.
This
is
basically
the
solution,
so
so
this
is,
this
is
finalized
right
and
one
thing
we
should
do
just
for
safety
is:
is
this
so
you
copy
the
finalized
callback?
A
Tear
down
and
once
from
from
gc
and
that's
bad
right,
we
should
never
call
the
users
finalizer
twice,
and
this
will
make
absolutely
sure
that
we
don't
and
then
this.
This
is
an
override
for
this
method
here,
which,
which
does
the
clear
week
right
to
to
make
sure
the
garbage
collector,
is
out
of
the
loop.
We
don't
want
the
garbage,
collector
anymore
right
and
then
it
chains
up
and
then
and
then
this
runs
so
so
okay,
so
I
I'll
keep
working
on
this
I'll.
Add
your
repro,
which
does
absolutely
nothing
in
in
master.
A
E
Yeah,
okay,
I
have
another
question:
I've
seen
the
comment
that
you
put
on
the
the
ref
base
delete
method,
the
that
there
is
a
chance
when
we
clear
the
week
and
but
the
v8
has
already
killed
the
weak
callback.
E
So
I
I
I
have
no
idea
that
if
the
case,
if
is,
is
effective
in
effective
here,
wait
are
you
talking
about
this
method
here,
yeah
you,
the
command!
You
have
put
about.
A
E
A
E
A
A
If
you
have
a
weak
reference
and-
and
you
explicitly
call
delete
on
on
the
weak
reference,
then
you
cannot
actually
delete
it
until
the
finalizer
runs,
because
there
is
a
finalizer
and
and
and
if,
if
environment
teardown
happens
before
the
finalizer,
then
then
it's
not
the
it's,
not
the
engine
that
runs
the
finalizer.
It's
the
environment,
teardown
that
runs
the
finalizer
either
way
we
have
to.
We
have
to
remove
the
finalizer
from
the
engine
we
have
to
remove.
We
have
to
clear
weak
so
that
the
engine
doesn't
run
it
as
well.
You
know
so
so.
E
Yeah,
I'm
wondering,
if
is
there
any
indication
that
the
once
you
see
when
v8
have
included
the
finalizers
and
we
run
the
delete
you
just
you
just
your
your
your
fix
and
just
delete
the
reference
and
the
defender
is
still
being
killed
and
it
is
still
being
going
to
be
wrong.
Well,.
A
E
A
No
this
this
here
this
here
this
is
this-
is
this-
is
much
older
right
this.
This
is.
This
covers
a
different
use
case
here.
This
is
this
covers
the
use
case
during
regular
execution,
not
during
not
during
tear
down.
So
that's
why
we
have
this.
That's
why
we
have
this
sort
of
ping-pong
between
delete
and
finalize
right.
That
covers
the
regular.
The
regular
use
case
this
here.
A
A
We
don't
want
the
garbage
collector
to
run
finalize
at
the
same
time
that
that
until
the
an
api
end
runs
the
finalize
right,
we
don't
want
that
to
happen,
because
that's
exactly
what
happened,
what
happened
was
finalize
all
from
tilde
and
api
end
calls
gc,
which
calls
finalize
you
know
which
which
returns
and
then
execution
continues
right
about
yeah.
Then,
okay,
so
then
this
comes
back
right
after
having
run
this
already
and
then
here
these
members
are
already
free
and
it
crashes
here
when
you
try
to
delete
because
that's
a
double
free.
A
So
that's
what
was
happening
but
yeah,
the
the
other
thing
we
can
do,
the
the
other
thing
we
can
do,
I
suppose.
Well,
no,
we
can't
really
do
that
like
like.
If,
if
you
don't
want
to
clear,
then
then
you
have
to
add
yet
another
sort
of
flag
that
says
you
know
the
finalizer
called
from
the
gc,
because
you
can
tell
whether
it's
called
from
gc
or
not.
If
it's
called
from
gc
isn't
tear
down
is
false
right.
A
E
So
if
the
v8
is
behaving
what
if
the
v8
will
not
cause
the
penalty,
if
we
clear
the
weak,
then
we
don't
have
to
do
such
a.
A
That's
right,
that's
right,
but
is
it
guaranteed
not
to
call
the
finalizer
if
you're,
clear,
weak
right
v8
is
not
under
our
control?
This
code
is
under
our
control,
so
so
now
that
now
that
I
I
spoke
about
this
with
you,
I'm
beginning
to
to
realize
that
maybe
we
should
use
like
the
inside
finalize
thing
instead
of
clear,
weak,
because
clear
weak
may
or
may
not
be
effective.
A
A
Yeah
yeah
yeah
yeah
it
did.
That
should
not
happen
right
because,
okay,
so
basically
what
we.
What
we're
trying
to
do
is
we're
trying
to
make
end
tear
down
be
identical
to
to
gc.
That's
the
goal
right.
This
nth
teardown
looks
exactly
like
gc
right,
meaning
that
finalize
runs
and
finalize
may
or
may
not
call
delete
right,
because
if,
if
the
code
inside,
if
the
user's
code
says
an
api
delete
reference,
and
we
call
that
from
finalize,
then
we
have
to
do
this.
Deferring
thing
right.
A
But
if
it
doesn't,
then
it
still
has
to
be
deleted
afterwards
right,
so
so
so
this
is
what
we
have
to
achieve
and-
and
we
have
achieved
this
in
most
cases
except
except
in
this
case-
where,
where
the
the
gc,
where
the
user's
finalizer
runs,
javascript
javascript,
is
allowed
to
execute,
javascript
causes
a
gc
and
the
gc
causes
a
finalize
right.
So
so,
in
that
case
we
have
a
problem
right
now.
A
A
And
in
that
case
it
would
just
be
like
it
would
just
be
like
if,
if,
if
not,
is
and
tear
down
and
tear
down
finalized
in
progress,
return
right.
E
A
Yes,
yes,
it
shouldn't
it
shouldn't
the
reason
why
it
shouldn't
is
because
in
your
repro
when
when
when
this
is
false,
meaning
that
the
gc
comes
back
to
do
the
finalize,
then
then
the
class
is
not
yet
deleted.
The
problem
in
the
the
problem
caused
by
your
repro
is
is
that
this
does
not
happen.
It
doesn't
return
here.
A
It
comes
here
right
and
it
runs
the
finalizer
again,
but
even
if
the
finalizer
doesn't
do
anything
this
it
gets
to
here,
and
then
this
actually
deletes
right
and
then
and
then
the
the
finalize
caused
by
the
gc
returns
and
the
finalize
caused
by
the
environment.
Teardown
resumes
right
here
and
it
deletes
again.
A
A
You
know
what
it's
it's
9,
11,
it's
getting
late!
Why
don't
we?
Why
don't?
We
continue
the
discussion
next
week,
all
right,
yeah,
okay,
great
awesome,
all
right
I'll,
create
both
solutions
and
and
and
I'll,
keep
this
solution
for
now
and
then
I'm
going
to
I'm
going
to
make
the
repro
into
into
a
test.
A
A
Issues
please
please
mention
them
now,
otherwise,
we'll
call
it
for
the
for
the
week
so
going
once
going
twice
gone.
Thank
you!
Everybody
for
attending
and
we'll
speak
again.
Next.