►
From YouTube: 2021-02-12-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
A
B
Yeah
there's,
I
think
I
have
a
pr
on
the
examples.
A
B
A
A
Sounds
like
we
are
working
along,
so
let
me
see
if
I
can
get
back
to
the
right.
That's
good
move
to
doc,
move
to
node
micro
time
tag
in
order
to
continue
the
tutorials.
B
A
Right,
maybe
I
was
looking
at
the
wrong.
I
didn't
go
quite
far
enough
back,
but
that
was
still
useful
right.
That's
where
I
should
have
gone
back:
okay,
okay,
milestone,
11
right,
so
renaming
an
api
is
something
more
appropriate
descriptive.
So
I
think
I've
seen
some
pr's
been
going
in
yeah.
I
don't
know
if
there's
too
much,
we
need
to
discuss
here,
but.
A
B
Yeah,
so
that's
ready
to
go
when
I
sat
down
to
put
it
in.
I
need
like
a
biography
and
a
job
title
and
all
of
that
stuff
from
kevin
right
as
the
co-presenter,
and
so
I
don't
have
that
yet.
B
Monday
is
the
deadline,
so
I
could.
I
could
submit
it
without
that
and
say
that
that
information
was
pending.
A
A
B
Right
and
then
I'll
mention
also
gabriel.
I
see
you've
you've
added
on
to
this
outline.
B
So,
okay,
perfect
and
then
so
I'll
mention,
gabriel
and
and
nicola
will
also
participate.
B
A
A
You
know
I
I
think
we
agreed
that
that
it
was
going
to
be
kevin
and
jim,
who
were
going
to
be
on
the
actual
submission.
A
A
A
To
right,
I
guess
we
talked
a
little
bit
about.
We
thought
it
was
interesting.
It
would
be
a
good
fit
for
like
a
supporting
library,
yeah.
A
E
So,
but
it's
like
we
have,
we,
we
have
kind
of
two
of
these
like
one
is
running
no
thread
and,
and
the
other
one
is
by
by
super
lockus.
I
believe
yeah
is
that
sort
of
fire
and
forget
threat,
say
function
that
takes
care
of
everything
behind
the
scenes
and
that
that
and
that
you
can
use
like
in
an
raii
way
right,
and
so
those
are
both
good
to
have,
but
I'm
not
sure
that
we
want
to
support
them
in
in
the
in
denote
that
on
api
library
right.
E
Yeah,
like
I
mean
off
the
top
of
my
head,
I
can
think
of
like
starting
like
a
new
know
that
on
api
extras
repo
and
then
just
have
that
sort
of
accumulate
these
things,
but
and
and
and
and
use
like
yeah.
I
guess
I
guess
these
these
these
editions.
They
don't
really
use
any
well.
No,
no!
They
can't
I'm
thinking
like
do.
E
They
need
anything
from
know
that
on
api
proper
in
order
to
work
right,
but
I
guess
they
don't,
because
because
you
know
they
can
always
just
use
the
c
c
api
right
if
they
need
anything
that
that
would
be
considered
internal.
You
know
maybe.
C
E
A
E
A
E
It
right,
that's
true,
that's
true,
yeah
yeah
yeah
and
it's
it's
basically
sort
of
like
you
know.
These
are
some
perspectives
on
the
thread.
Safe
function,
you
know
like
one
of
them
is,
is
to
just
well.
Both
of
them
actually
are
are
to
just
sort
of
you
know,
create
it
and
throw
it
away.
You
know,
make
the
make
the
user
interface
for
the
threat
say
function
as
simple
as
possible.
A
Here,
it'll,
you
know,
provide
a
place
for
people
to
get
the
code
and
use
it,
but
doesn't
imply
maintenance,
you
know,
otherwise
you
know
creating
if
you're,
if
they
are
interested
in
creating
their
own
module.
We'd,
certainly
reference
it
and
stuff
like
that
right,
yeah,
exactly
okay,
so
we
discussed.
C
C
C
I
don't
know
the
right
place:
no,
where
to
to
expose
this
information.
C
In
other
open
source
project,
for
example,
I
saw
a
specific
repository
called,
for
example,
ecosystem
and
there
you
can
see
all
the
plugins
or.
C
Module
that
you
can
use-
or
maybe
we
can
list
these
or
know
that
on
api
rainbow,
but
in
that
case
yeah
these
extras
should
be
dependent
on
other
dawn
api,
in
my
opinion,
so
I
don't
know.
C
Yeah,
if
the
node
one
example
and.
C
My
so
the
example
is
a
way
to.
C
C
Expose
how
to
do
something
to
who
want
to
learn
about
the
native
adult
in
general.
So.
E
Yeah,
I
can
kind
of
see
nicola's
point
too,
like
if
we
add
test
an
example,
then
then
we
expect
people
to
copy
it
verbatim,
so
there
will
be
like
a
ton
of
verbatim
copies
of
it
going
around,
possibly
slightly
modified
and
all
that
you
know
to
suit
individual
purposes,
whereas
if
we
did,
you
know
we
could
potentially
make
it
into
one
of
these
extras
libraries,
you
know
with
a
big
fat,
you
know
blur,
but
at
the
top
of
the
readme
that
says
you
know
that
this
this
isn't.
E
You
know
and
we
do
not
actively
maintain
it,
and-
and
so
you
know
we
would
be
expected
to
to
you
know-
maybe
at
least
once
in
a
while
look
at
it,
but
otherwise
just
concentrate
on
know
that
on
api
right,
we
we
might
even
we
might
even
hand
out
and
hand
out
some
some
commit
rights
to
to
to
the
contributors
that
that
have
landed
their
stuff
in
that
repo.
You
know,
I
guess
I
guess
what
I'm
saying
is.
It
could
be
like
on
the
order
of
node
add-on
examples
like
that.
E
A
E
A
B
A
A
My
opinion
it's
better
to
if,
if,
if
something
is
unsupported,
you
should
kind
of
be
like
hey,
I'm
willing
to
understand
what's
going
on
there,
so
I
can
fix
something
right.
Yeah
easier,
doesn't
necessarily
help.
So
I
yeah
it's
a
it's.
It's
a
tough
one
and
it's
kind
of
like
creating
a
repo
where
we're
not
going
to
respond
to
questions
or
anything
writers,
yeah
yeah,
that's
yeah,.
A
Of
like
hey
it's
here,
you
can
require
it,
but
don't
you
know,
nobody's
gonna.
Look.
I
don't
know
about
that
either
right,
that's
kind
of
where
I
was
like,
but
I
also
I
do
get
the
point
about
you
know.
The
main
goal
of
examples
is
help
people
learn.
This
is
not
really
in
that
yeah.
E
A
E
Yeah
I
mean
I
ideally
I
think
what
would
happen
is
is
that
you
know
that
community
members
would
would
sort
of
not
only
raise
issues
but
also
fix
them,
and
they
would
be
mostly.
E
You
know,
working
in
this
repo.
E
You
know
and
then
right
you
know
and
then
well
I,
but
the
the
problem
is
bootstrapping
it
right
like
basically,
basically
I
mean
we,
we
could
we
we
could
ask,
we
could
ask
this
person
and
maybe
super
lockers
if
they'd
be
willing
to
to
you,
know
post
their
code
there
and
then
maintain
their
code
right,
because
you
know
their
code
would
be
exposed
to
lots
of
users,
and
presumably
I
mean
it
works
for
them
right
right,
so
so
on
on
one
end
of
the
spectrum,
he
would
just
kind
of
sit
there
and
they'd
be
sort
of
sitting
there
as
well,
and
all
would
be
well
right
now,
on
the
other.
E
B
E
From
from
having
these
bugs
found
right
and
it
would
help
their
own
code
as
well,
and
so
that
might
be
one
way
to
bootstrap
the
ecosystem,
so
you
know,
and
and
you
know,
on
the
other
hand,
of
course,
it
could
just
open
the
floodgates
to
like
a
myriad
contributions,
and
we
can't
give
everybody
commit
access.
Who
has
a
piece
of
code
in
there
right
right.
C
E
E
A
E
A
E
A
E
C
E
E
A
D
Spins
on
the
thread
say:
functions
yeah
wrappers
for
the.
How
about
that
function?.
E
E
A
E
A
A
A
A
B
B
I'd
I'd
still
like
to
keep
on
the
table
the
idea
that
maintainers
could
create
their
own
repos
and
that
we
would
just
have
a
a
directory
of
right,
interesting,
interesting
repos,
because
that
could
be.
That
could
be
adequate.
E
E
A
E
I
still
there's
still
a
response,
so
let's
maybe
can
you
can
you
maybe
mention
the
the
author
of
this
one
and
super
locust
as
well,
because
because
they
also
have
have
a
pr
that
that
is
similar
in
vain.
I.
A
A
A
Okay,
so
I
think
I
think
that's
good
any
more
discussion
on
that
one
before
we
move
on.
A
A
So
this
one-
I
don't
know
if
you
have
any
oh
legit
legend
cass-
was
going
to
take
a
look
at
this.
So
we'll
wait
to
hear
back
from
him.
I
I
do
want
to
take
the
opportunity
here.
I
was
actually
looking
at
another
issue
in
refnappy
and
there
was
a
case
where
you
know
I
would
have
liked
to
have
been
able
to
dynamically
allocate
an
instance
of
a
reference.
A
E
Actually
one
does
keep
like
an
object
reference
you
know
in,
like
you
can
add
an
object
reference
to
like
an
add-on
instance,
and
so
that
would
be
heap
allocated
right.
I
mean
you
would
have
to
because,
because
you
know
with
a
with
a
with
an
add-on
like
with,
within
with
an
instance
of
the
add-on
class,
meaning
your
entire
add-on,
everything
would
have
to
be
heap
allocated
because
it's
stored
on
the
environment.
E
I
meant
stack
allocated
so
I
mean
basically,
this
talks
about
copying
a
reference
right
right.
So
so
you
know
copying
a
reference
means.
Now
you
have
two
references
which
all
refer
to
the
same
object
right
so.
E
I
think,
like
I
think,
there's
no
problem
creating
a
reference
that
is
stored
like
heap
allocated
and
and
the
same
thing
can
be
said
for
for
for
stack
allocated
right
because
you
just
say
like
nappy
reference,
colon,
colon
well
actually
yeah
yeah
yeah,
because
it's
like
object,
quality.
Persistent,
I
think,
if
I
remember
correctly,
is,
is
how
you
create
a
a
reference
right.
E
Let
me
check
the
code,
but
but
either
way
in
terms
of
in
terms
of
addressing
this
issue,
you
know
you
can
copy
a
reference
just
by
dereferencing
it
and
creating
a
new
one
right
I
mean
I
guess
we
could
create
like
a
copy
copy
operator,
that
that
does
that
you
know
where
it
just
gets
the
value
of
the
reference,
and
then
it
returns
a
new
reference
to
that
value,
and
so
the
original
reference
is
is
in
place,
and
now
there
is
a
new
reference,
but
this.
E
No,
no,
no!
No!
No!
No
it
wouldn't
it
wouldn't
increment
the
reference
count,
because
it
would,
it
would
create
a
brand
new
reference.
So
if
you,
if
you
go
back
to
like
core
node
api,
you
would
be
like
right.
Yeah,
okay,
yes
got
it
an
api
reference,
get
value
and
then
an
api
create
reference,
yeah,
no,
no
yeah,
yeah.
Okay.
That
would
make
some
sense.
A
A
Legendary
cast
was
going
to
research
and
add
some
comments
there,
yeah
so
but
the
question
I
was
back
to
like
with
the
current
api.
A
E
E
I
don't
see
why
the
destination,
whether
that
be
stack
or
or
or
heap,
should
matter
when
creating
a
reference.
But
let
me
just
double
check.
E
Class
reference
there,
it
is
so
I
mean
yeah,
I
mean
it
it's
it's
just
like.
Let
me
see
type
name,
t.
E
E
Otherwise,
it
will
fail,
because
we
can't
make
references
to
primitive
types,
but
the
bottom
line
is
it
returns,
a
value
of
type
and
api
called
reference
angle
brackets
t
right,
and
so
that
can
be
assigned
to
yeah.
A
A
Okay,
so
that
I
mean
it
sounds
like
there's
no
fundamental
reason
why
we
think
that
shouldn't
work,
it
could
just
be
me
not
not
getting
the
c
plus
plus
right
to
make
it
work,
but
it
kind
of
looked
like
you
know.
It's
like.
I
know
in
some
cases,
definitely
like
a
lot
of
the
the
v8
structures
are
like
no
yeah
stock.
E
And
delete
okay,
so
okay,
so
we
have.
We
have
something:
that's
that's
statically
declared
in
a
test,
slash
reference
dot
cc,
so
we
have
static
reference
buffer.
You
in
day
t
week
and
then
you
say
week
equals
week.
E
A
Tess
reference
object.
Reference
is
that.
A
E
A
A
Where
is
that
assignment
week?
Okay,
so
that's
using,
but
that
is
weak
as
something.
A
D
A
E
A
Right
so
maybe
I
just
need
to
use
persist,
okay,
that
helps.
Thank
you
very
much.
I
I
will
not
derail
us
any
further
on
that,
but
see.
Can
I
get
back
to
right
so,
okay,
so
legend,
just
gonna.
Look
at
that
original
one
right!
Stale
issues!
Sorry,
okay!
So
we've
got
a
next
step
on
that
one,
and
then
this
one
here.
D
A
Okay,
so
those
were
the
stale
issues,
tracking
issues
for
things
that
were
ported,
so
I
guess
nothing
too
new
there,
but
we'll
do
our
npm
api
look
just
to.
A
C
You
you,
you
could
use
nfpm
start
website
okay,
so
if
you
want
to,
I
push
on
the
chat.
Okay,
if
you
want,
if
you
want
to
see.
C
A
Okay,
so
that's
good:
let's
go
back
to
the
regularly
scheduled
agenda
if
I
can
find
that
where
is
the
right
issue
here?
A
A
Sorry
now
I
think
I've
lost
right
this
one,
okay,
review
external
examples.
I
know
I
haven't
gotten
to
that
debug
testing
for
add-ons.
No,
I
guess
list
of
issues
raised
by
module
owners.
If
we
go
to.
This
is
a
little
bit
stale.
I
guess,
but
if
we
go
to
github
and
take
a
quick
look
at
node
add-on
api,
are
there
any
issues
that
people
want
to
highlight
or
bring
out.
A
D
D
E
Reference
over
there,
that's
about
the
only
one.
I
think
I
think
that
one's
ready,
but
I
did
want
to
ask
you
one
thing:
let
me
just
get
the
pr
the
pr
is
37303.
D
E
Yeah
yeah
and
you
were
right-
I
did
miss
the
case
where,
where
during
environment
tear
down
it
does
not
delete
the
reference
right,
in
that
case
it
would,
it
would
still
get
deleted,
but
it
would
execute
the
finalizer
twice
so
so
then
I
changed
it
so
that
the
finalizer
only
gets
executed
once
and
all
the
tests
pass.
However,
if
you
look
at
the
code,
there
are
two
ways
of
solving
this
right.
See
I
see
here,
I
move
the
finalize
rand
equals
true.
E
I
move
that
out
of
this
else
that
you
had
down
here,
right,
okay
and
and
so
if
we
keep
the
finalized
rant
true
inside
that
else,
then
then
we
can
prevent
the
the
the
finalizer
from
getting
called
twice
during
environment
teardown
by
checking
whether
the
finalized
ran
equals.
True
right,
if
you,
if
you
go
above,
if
you
scroll
up
a
little
bit
where
we
call
the
finalizer
see,
we
could
add
to
this
if
statement
another
condition
that
says
if,
if,
if
not
ran
here,
I'm.
C
E
Now,
in
the
case
where
it's
not
environment,
tear
down,
then
then
I
I,
I
suspect,
it's
okay,
because
all
the
tests
passed
right,
but
in
that
case
the
finalizer
runs
when
the
garbage
collector
is
already
in
the
process
of
running
the
finalizer
right,
and
so
so.
If
we
set
finalize
rand
to
true
here,
then
then
it
will
it.
It
will
not
exit
without
deleting
it
will
call
delete
afterwards
right
and
then
that
delete
will
actually
delete
because
because
well,
the
analyzer
has
already
run
so
once
again.
C
E
So
so
so
it's
kind
of
you
know
this
this.
This
change
to
move
the
finalized
rant
equals
true
out
of
there
kind
of
upsets
the
code
a
little
more
than
it
should,
but
on
the
other
hand,
it
does
seem
to
work
everywhere
now,
if
we,
if,
if
we,
if
we
undo
this
change-
and
we
put
the
finalize
back
finalize
running
true
back
into
this
else
statement-
then
we
also
have
to
check
for
finalize,
ran
equal
equal,
false
before
calling
the
finalizer
otherwise
during
environment
teardown,
it's
going
to
call
the
finalizer
twice.
A
A
E
Right
there
is,
there
is
one
sort
of
philosophical.
If
you
will
consideration
right.
If,
if
the
finalizer
has
in
fact
run,
then
we
should
set
the
finalized
iran
to
true.
It
should
not
be
conditional
right
because,
like
the
finalizer
ran,
why
are
we
checking
whether
we
set
it
to
true
or
not?
We
should
set
it
to
true
because
the
finalizer
ran,
and
we
want
to
mark
that
occasion
unambiguously
right.
E
E
B
E
A
It's
using
finalize
ran
you're
changing
whether
or
not
it's
actually
gonna
whether
it's
gonna
see
that,
because,
basically
now
it's
always
gonna
say
that
the
finalize
is
run,
and
so,
when
you
hit
that
delete
you'll
be
deleting
when
you
wouldn't
have
otherwise
yeah.
Let
me
think
about
that.
That's
a
good
point,
so
kind
of
why
I'm
like
you
know,
there's
there's
it's
sort
of
like.
E
A
E
E
A
That's
where
it's
back
to
like
I.
I
think
this
is
there's
some
very
it's
very
subtle
in
that,
like
actually
yeah.
The
reason
it's
where
it
is
is
because
we
don't
want
it
to
be
set
before
that,
delete
and
so
moving.
It
actually
could
yeah.
Okay,
okay,
adding
a
check
of
it.
Somewhere
else
is
much
safer
than
trying.
E
To
tinker
with
the
order:
okay,
okay,
yeah,
okay,
no
worries,
okay!
So
then,
so
then
I'll
change,
this
I'll
change
this
to
to
keep
the
finalize
around
where
it
is
and
then
I'll
add
the
additional
check
before
we
actually
call
the
finalizer,
because
that
also
makes
sense
right
to
to
to
check
there
like
if
the
finalizer
has
already
run,
then
don't
run
it
again.
It's
as
simple
as
that
and
then,
and
then
that
that
should
be
equally
correct.
A
D
A
Oh,
I
just
think
I
just
got
into
it
which,
which
line?
Did
you
say
it
was
2.
D
E
A
E
E
Oh,
no,
no,
no!
No!
No!
The
only
way
to
okay,
so
finalize
finalize,
is
being
called
from
the
actual
static
v8
provided
finalizer.
That's
there.
So
it's
called
from
two
places
from
the
va
provided:
finalizer
yeah.
Finalize
callback
is
a
very
simple
function
that
just
that
just
calls
the
instance
method.
That's
all!
E
E
So
so
you
know
if
it's
called
with
what
is
that
is
and
tear
down
false.
That
means
it's
being
called
from
the
garbage
collector
right,
and
so
this
is
the
first
and
last
time
that
it's
ever
gonna
get
called
right,
and
so
so
I
I
don't
know
that
we
want
to
defer
there,
because
if
we
defer
there,
then
then
you
know
we're,
never
gonna
delete.
E
I
think
that
the
deferring
refers
to
when,
when
the
user
explicitly
deletes
in
in
the
finalizer,
then
you
want
to
keep
going
so
that
so
that
so
you
know
where
you
say
this
is
safe
because
right
see
it
says
here
this
you,
you
skipping.
C
E
Yeah
yeah
yeah.
It
says
it
says:
oh
boy,
this
is
safe
because
if
a
request
to
delete
a
reference
is
made
in
the
finalized
callback,
it
will
defer
deletion
right.
So
it's
the
delete
function
above
this
function
that
does
the
deferring
not
this
function.
This
function
is
supposed
to
actually
delete
right
right.
So
so,
by
the
time
the
finalizer
runs,
things
should
be
set
to
delete,
so
it
should
actually
delete
right-
and
I
think
you're
using
delete
self
here
to
to
mark
the
the
deferring,
because
if
you
go
up,
you
can
actually
expand
or
no.
E
This
is
the
file,
so
you
can
just
go
up
into
delete,
see
see
here.
It
says
you
know
if,
if
it's
a
strong
reference,
if
delete
self
is
true
or
reference
finalize
rand,
then
delete
yourself
right.
So
otherwise
you
set
delete
self
to
true
right,
so
meaning
the
the
user
has
requested
it.
But
you
can't
quite
delete
it
yet
because
the
finalizer
may
or
may
not
have
run
right
right.
E
So
if
delete
self
is
already
set
to
true,
because
that's
the
nature
of
the
reference,
then
then
you
know,
then
this
code
will
delete
it
right
right
either
way,
whether
it
was
called
explicitly
or
whether
it
was
called
from
from
from
the
finalizer.
It
will
delete
it
right.
So
this
code
is
the
one
that
does
the
deferring.
E
E
The
finalizer
is
getting
called
twice,
that's
the
problem,
so
I
I
added
a
test
case
where
you
have
a
strong
reference
and
you
wait
until
environment
tear
down
right
and
then
at
environment
tear
down
the
finalizer
must
get
called
whether
the
reference
is
strong
or
not.
It
must
get
called.
There's
no
question
about
it
because
the
environment's
going
down
right.
E
So
so
then
the
problem
was
because
it's
a
strong
reference,
you
run
the
finalizer
and
it
deletes
itself
because
it's
a
strong
reference
right
and
so
delete
gets
called
because
there's
nf
tear
down
and
then
it's
a
strong
reference.
So
so
it
deletes
it
and
then
and
then
the
rest
of
the
code,
even
though
you
said
it
was
safe,
it
was
not
safe
right,
and
so
so
that's
why
I
added
the
the
the
the
condition
at
line
275
right.
E
If
it
isn't
tear
down,
then
you
have
to
pretend
it's
a
weak
reference
because
it
has
to
because
when
you
do
call
delete,
it
has
to
defer
right,
but
then,
but
then,
if
it
differs,
then
then
it
it
ends
up
back
in
the
destructor
and
it
calls
delete
again,
in
which
case
the
finalizer
runs
again,
because
the
only
the
only
condition
preventing
the
finalizer
from
running
is.
If
there
is
no
finalizer.
A
E
A
A
E
C
E
If
finalize
callback,
not
equal,
null,
pointer
or
or
or
finalize,
run
equals
false
right
or
no
sorry
and
finalize
run
equals
false.
Then
then
you
enter
here
right,
but
we
could.
We
could
add,
to
that
finalize
run,
equals
false
and
is
m
tear
down
right.
You
know
what
I
mean.
A
E
So
that's
why
you
have
to
you
know
if,
in
a
in
a
in
a
in
a
garbage
collection
scenario,
a
finalize
will
only
be
called,
I
mean
finalize
will
be
called
by
the
garbage,
collector
right
and
then
and
then
it
will
delete,
because,
let's
see
why
that's
a
good
question
so
finally,.
E
Sorry,
I
know
why
I'm
sorry,
let
me
just
continue
my
yeah
okay,
so
the
finalizer
under
normal
circumstances,
only
runs
if
it's
a
weak
reference.
If
it's
a
strong
reference,
the
finalizer
will
never
run
right.
So
the
fact
that
finalizer
is
running
means
that
it's
a
weak
reference
and
so
and
so,
and
so
what
and
yeah
okay?
Yes,
that's
right.
Yeah,
it's
a
weak
reference,
and
so,
if
delete
self
is
set
to
true,
it
will
actually
physically
delete
the
reference.
If
delete
self
is
set
to
false,
then
that
means
the
user.
E
For
some
strange
reason
wants
to
hang
on
to
the
reference,
even
though
it's
already
finalized,
okay,
more
power
to
them
right.
So
in
that
case,
the
the
delete
self
marks.
The
fact
that
that
the
reference
you
know
it
marks
the
user's
choice.
However,
if
the
user
does
delete
the
reference
inside
an
actual
finalizer
call,
then
delete
will
have
executed,
which
will
have
deferred
right
and
delete.
Self
will
be
true
here,
in
which
case
it
will
actually
delete
the
reference.
So
that's
how
we
handle
the
regular
finalization
case
right
right.
C
E
In
that,
in
the
case
of
environment
teardown,
if
the
reference
is
strong,
we
we
have
to
pretend
the
reference
is
weak.
We
have
to
make
it
so
because
we
have
to
do
this
cycle
right,
but
so
far
in
islam
tear
down.
We
had
this
condition
here
that
that
that
it
will
actually
delete
right,
and
so,
if,
if
we
don't
delete,
if
we
don't
actually
delete
here,
then
it's
going
to
end
up
calling
finalize
again
because
it
goes
back
to
the
environment
teardown.
A
E
E
Oh,
I
know
why?
Okay,
yes,
yes,
yes,
yes,
okay,
so
delete
delete.
The
delete
function
doesn't
actually
delete
a
weak
reference.
It
refuses
to
delete
the
weak
reference
right,
but
we
just
marked
the
reference
as
weak,
and
so
that's
why
it's
not
deleting
and
that's
why
it's
returning
to
the
to
the
destructor
holy
cow.
This
is
this
is
quite
a
quite
a
bit
of
spaghetti
here,
yeah,
so.
E
A
E
A
E
Okay,
good,
so
so
then,
so
then
the
the
other
conceptual
issue
is
right.
If
you
run
the
finalizer,
whether
it's
null
or
not,
the
you
know,
conceptually,
you
run
the
final
answer.
Then
you
want
to
unconditionally
mark
that
it
ran
because
it's
simply
true
right,
like
you
know
what
I
mean
like
you
know,
you
want
either
potency
right.
So
so
you
know
you're
on
the
finalizer,
you
mark
it
as
true
right
and
normally
idempotency
means.
If
finalizer
didn't
run,
then
final
then
run
finalizer
and
mark
finalize
iran
right.
E
E
C
D
E
C
E
A
E
Oh
yeah
yeah
yeah
yeah.
Yes,
if,
if
if
we
move
that
out
and
delete
self
is
false
right,
then
then
we
will
retain
the
scenario
where
the
user
wants
to
keep
around
and
a
a
useless
reference,
because
because
finalized
may
be
true
but
delete
self
is
false,
and
so
it's
never
going
to
call
delete
right
until
the
user
explicitly
calls
delete,
in
which
case
finalize
ran
is
true.
The
reference
is
weak,
doesn't
matter
because
finalized
rand
being
true
is
one
of
the
conditions
for
actually
deleting
it.
E
E
Yeah,
okay,
the
finalizer
can
call
back
into
javascript
and
say:
okay,
the
finalizer
has
run
and
then
javascript
will
will
call
like
a
native
binding,
which
explicitly
deletes
the
reference.
So
I
will
add
a
test
here
that
will
that
will
address
that
scenario.
I
will
intentionally
keep
a
useless
left
reference
hanging
around.
E
Okay,
wait
a
minute
I
I
was
of
the
impression
that
you
were
okay
with
keeping
it
keeping
it
where
it
is
in
this
pr.
Ie,
no.
E
A
C
A
A
E
E
A
Delete
delete.
E
Oh,
I
don't
know
off
the
top
of
my
head,
but
but
if
you
search
for.
E
Yeah
so
see
so
delete
self
is
also
a
condition
for
immediately
deleting
whether
the
finalizer
has
run
or
not
doesn't
matter.
If
it's
a
delete
self
reference
and
you
you
end
up
inside
delete,
you
delete
the
reference
which,
which
makes
perfect
sense,
because
you
do
this
at
the
end
of
the
finalizer.
This
is
your
last
chance
to
delete
the
reference
before
it
leaks
right,
because
the
gc
will
never
call
the
finalizer
again.
So
if
the
reference
itself
is
set
to
self-delete,
then
it
doesn't
matter
whether
to
finalize
finalizer
ran
or
not.
E
You
will
immediately
delete
the
reference.
The
only
time
you
will
defer
is
if
delete
self
is
false
and
the
reference
is
weak
and
the
finalizer
hasn't
run
yet
right,
meaning
that
meaning
that
I
don't
even
know
what
that
means
honestly
like.
Why
would
that
ever
happen?
Why
would
you
call
delete,
I
guess,
weak
reference?
Delete
self
is
false:
yeah!
Okay!
Yes,
yes,
yes,
okay!
I
know
the
circumstances
that
this
covers.
Is
you
have
a
you.
You
have
created
a
weak
reference
and
you
call
nappy
delete
reference
before
the
finalizer
runs
right.
E
A
E
A
A
E
Yeah
basically
yeah,
I
guess
so
yeah,
because
because
delete
self
takes
care
of
that
right.
So
if
this.
A
E
Oh,
no,
no!
No,
because
it's
not
no
it
it
doesn't.
It
doesn't
the
way
the
code
currently
is
on
the
main
branch.
It's
an
else
right.
So
either
you
delete
yourself
or
you
you,
you
safely
set
that
to
true
right,
but
right
now,
you're
setting
it
safely
to
true
before
you
delete
yourself.
So
it's
so.
It's
also
guaranteed
to
be
safe.
A
A
A
E
I'll
I'll
change
it
I'll
because
finalize
ram
will
be
marked
as
true
in
this
case
and
it'll
it'll
just
get
back
to
the
to
the
destructor
and
then
it'll
come
back
in
here
because
so
the
destructor
of
so
the
an
api
environment.
Destructor
will
call
this
function
twice,
but
it
will
only
call
the
user's
function
once
because
the
second
time
around
finalize
rand
will
be
marked
as
true
right.
So
so
then,.
A
E
Oh,
you
know
what
you
know,
what
that's
that's
an
even
that's
even
better,
because
that's
that's
an
important
right
there.
It's
like,
if
finalize
callback,
not
equal,
now
pointer,
call
the
finalizer
set
finalize
call
back
to
null
pointer
because
then
no
matter
what
it's
impossible
to
call
it
twice
unless
we're,
unless
we're
intentionally
dereferencing
a
null
pointer,
which
is
absurd,
right,
yeah
yeah,
because
yeah.
E
A
A
The
first
one
is,
of
course,
I
think,
a
little
bit
better
comment
on
273.