►
From YouTube: Node.js N-API Team meeting - June 24th, 2019
Description
A
A
B
B
To
make
sure
there
aren't
any
yeah
yeah
exactly
yeah,
so
so
then
so
then
there
would
be
one
final
PR
which
has
to
trickle
down
to
eight,
which
is
which
is
you
actually
mark
them
as
stable
and
and
you
know,
rearrange
the
headers
and
they're
like
nappy
version,
five
and
yeah.
No,
that
makes
sense.
Yeah
I
think
that
sounds.
B
A
D
B
A
B
B
A
B
B
D
B
A
B
B
A
B
D
B
C
A
A
C
A
D
B
F
A
B
B
A
A
E
B
But
yeah
regarding
regarding
that
I
was
I
was
hoping.
One
of
you
might
be
able
to
to
have
a
look
at
the
threats,
a
function
PR
because
I
think
it's
ready
to
go
like
I've
gone
through
it,
and
we've
actually
had
we've
actually
had
somebody
like
really
put
it
through
its
paces
and
and
and
find
find
a
find
like
like
a
bug
with
it,
and
so
we
fix
that
as
well.
So
I
I
really
don't
see
anything
else
that
that
that
needs
to
be
changed
and
and
Kevin
Kevin
had
the
documentation
in
a
separate
er.
B
So
so,
once
once
we
have,
it
landed,
the
the
documentation
can
go
in
as
well.
Okay,
so
I
think
I
think
we
should.
We
should
have
some
more
eyes
on
it
and
then
that
can
go
as
far
as
I
mean
I've
already
approved
it,
and
but
I
kind
of
don't
want
to
land
it
until
you
know
you
also
have
a
look
at
it
just
just
in
case
okay,
yeah.
A
A
D
E
D
D
B
A
B
Oh
in
the
quarry,
but
there's
there's
there's
some
there's
something
new
and
API
stuff
going
on
like
the
one
that
I'm
involved
in
is
this
type
tagging
thing
turns
out
that
using
using
just
snappy
rap
may
not
give
you
nappy,
wrap,
plus
nappy
defined
class
may
not
give
you
a
strong
enough
indication
that
an
incoming
object
is
read.
Does
really
have
the
the
right
pointer
inside
that
when
you
unwrap
it,
so
it
will.
If
you're,
calling
if
it
is
that
this
parameter
of
a
prototype
method,
then
it's
guaranteed
to
have
the
right
pointer.
B
A
B
In
a
perfectly
generic
scenario,
you
should
be
checking
right,
but
in
practice
yes,
most
most
native
add-ons
are
our
fronted
by
by
javascript
code,
which
which
makes
use
of
them.
So
so
yes
and
no
right,
but
if
you,
if
you,
if
your
native
add-on,
if
you
have
chosen
to
take
the
path
where
you
implement
your
abstractions
in
your
native
add-on,
so
instead
of
you
know,
exporting
just
a
bunch
of
functions
and
then
wrapping
those
functions
into
classes
and
a
nice
interface
on
the
JavaScript
side.
B
A
Yeah
so,
but
it's
it's
not
implausible,
doesn't
sound
strong
to
me
right
yeah.
If
you
know
what
I
mean
like
I'm,
trying
to
just
understand
that
like
cuz
this
every
time
we
expand
the
surface,
it's
more
maintenance
and
more
so
like.
If
it's
like
well
yeah,
this
could
happen,
but
never
will
in
real
life.
Yeah
yeah
I.
A
B
So
so
so
that's
yeah,
that's
that's
that's.
Basically.
The
crux
of
the
matter
is
I
mean
I,
I
I
think
I
submitted
a
PR
that
implements
a
version
of
this
interface,
but
I'm
not
super
keen
on
landing
it
until
we
have
established
that
it
is
in
fact
it
isn't
like
something
we
want
to
add
to
anything
I'm
perfectly
happy
if,
if
we
end
up
closing
the
PR
without
landing
it
because.
A
B
It's
the
truth
is
that
I'm
beginning
to
think
that
that
this
whole
this
whole
wrapping
and
and
then
basically
attaching
native
data
to
to
JavaScript
objects.
Api
is
it
has
it
has
sort
of
evolved
organically
like
had
we
were
we
to
start
it
today
we
would
probably
start
with
type
tagging.
You
know
and
the
other
thought
that
I
had
was
that
that
actually
Jerry
script.
Does
it
really
well
because
Jerry's
group
did
type
tagging
from
from
day
zero
with
this
API
right?
So.
B
With
type
tagging,
meaning
that
you
would
so
so
in
Jerry
script,
when
you
attach
a
native
pointer
to
a
JavaScript
object,
you
you
you,
you
don't
allocate
anything
so
so
Jerry
script.
Does
the
memory
management
for
you?
Okay,
that's
a
little
overboard
for
for
nodejs,
but
still,
basically,
what
you?
What
you
tell
Jerry
script
is.
B
Please
please
give
me
please
give
me
a
native
pointer
to
this
object
and
here's
a
structure
that
contains
a
size
and
and
two
two
function.
Pointers
and,
and
one
of
them
is
a
constructor.
One
of
them
is
a
destructor
and
the
size
is
obviously
the
size
of
the
memory
of
the
resulting
object
and
and
that
structure
is
stored
at
a
global
static
address.
So
the
address
of
the
structure
can
serve
as
the
type
tag,
so
you
pass
this
pointer
into
Jerry
script.
B
Jscript
allocates
the
memory
for
you
and
by
the
way,
it
now
has
all
the
information
to
also
destroy
the
object
to
both
construct
that
right,
because
the
the
type
tag
is
at
once
also
like,
like
a
type
information
and
the
lifecycle
management
information
resource
for
Jerry
script
as
well.
So
then
we
have
type
tagging
and
and
and
we
have
lifecycle
management
with
a
single
API
right
and
you
know,
I
mean
obviously
for
no
GS.
This
is
not
an
option,
because
the
allocator
for
the
pointer
can
be
different.
B
C
B
So
so
either
way
it
is
doable
and-
and
it
seems
that
it
is
desirable
to
like
I-
was
hoping
we
could.
We
could
get
away
with
with
with
a
single
pointer
and
and
with
with
JavaScript,
with
the
JavaScript
type
system
as
the
type
tagging,
but
but
obviously
for
for
the
reporter
of
that
issue.
That's
not
a
strong
enough
guarantee.
So
we
need
to
decide
whether
whether
they're,
whether
there
is
a
common
enough
use
case
that
it
wore
and.
A
C
A
B
Think,
which
is
then
the
way
I
think
about
it.
The
way
I
think
about
it
is
that
as
soon
as
you
have
as
soon
as
you
have
an
interaction
between
two
wrapped
instances,
then
you
need
this
because
if
you
just
have,
if
you
just
have
prototype
methods
on
on
one
wrapped
instance,
then
you
never
need
this
right.
So
if
all
the
prototype
methods
of
all
the
wrapped
instances
take
primitive
data,
then
you're
all
set
right.
B
Don't
get
me
wrong,
but
if
you,
if
you
structure
your
API
in
such
a
way
that
that
you
know
the
the
like,
for
example,
if
you
want
to
retrieve
records
from
a
query
right,
you
call
you
call
something
like
database
handled,
dot,
retrieve
records
and
you
pass
it.
The
query
handle
right
as
the
first
parameter.
At
that
point,
you
need
to
unwrap
the
query
handle,
but
you
cannot
know
that
that
the
user
used
your
API
correctly.
They
may
have
passed
in
something,
that's
not
a
query,
handle
right
accidentally
and
that
right,
you're.
C
B
Object
exactly
yeah,
so
so
I
mean
if
they
passing
a
plain
JavaScript
object.
Then
the
check
is
very
simple.
It's
like
this
is
not
the
query
handle
because
it
doesn't
have
a
native
point
right,
but
if
it
does
have
a
native
pointer,
then
what
is
it
you
know?
That's
the
problem,
did
you
do
you
can
check
you
can
check?
Is
the
object
passed
in
instance,
of
write,
a
query
handle
class
right?
That's
it
that's
a
fairly
strong
indication
that
it's
okay,
but
it
doesn't
survive
prototype
manipulation
that
that
was
that
was
the.
B
B
C
A
B
Well,
I
mean
yeah,
but
I
don't
know
if
there
are
too
many
other
places
where,
where
you're
retrieving
native
pointers
right,
which
don't
have
any
type
information,
so
you
know
yes,
prototype
manipulation
is,
is
one
of
the
Achilles
heels
of
JavaScript.
We
all
know
that
right
now,
but
yes,
within
that,
you
know
it
does
work
pretty
well.
A
B
About
that
like,
basically,
basically
you
know
if,
if
the,
if
the
JavaScript
engine
supports
attaching
a
native
pointer
to
two
to
a
JavaScript
object
and
we're
done
so-
which
we
already
depend
on
right,
yeah,
exactly
yeah
I
mean
you
know
if
you
have
a
JavaScript
engine
that
doesn't
support
that
it's
not
really
extensible
in
any
way,
it's
just
living
in
a
vacuum.
At
that
point,
you
can't
really
write
any
bindings
for
it.
B
So
so,
in
terms
of
not
being
implementable,
I
don't
I,
don't
think
that's
a
problem,
but
the
question
is,
you
know:
do
we
want
to
have
even
more
it
gets
now
another
another
sort
of
thread
in
this
discussion
is
is,
is
is
Timothy
who,
who
said
to
please
hold
off
on
this
PR,
because
he
wants
to
do
some
more
deep
thinking
about
it
and
and
he's
he's
he's
a
good
person
to
be
thinking
about
this,
because
he's
also
had
many
good
ideas
regarding
the
original
nappy
wrap.
So
he
drove
a
lot
of
this.
B
A
B
B
It
is
strictly
additive
during
its
life
cycle,
so
you
know,
because
if
you,
if
you
start
unloading
add-ons
and
then
rewriting
into
the
same
thread,
while
it's
still
running
yep,
then
then
these
these
these
are
you
know
you
can
you
can
end
up
assigning
the
same
address
to
to
a
different
types
right.
You
know,
so
there
doesn't
seem
to
be
any
danger
of
this
happening
now,
because
we
are
still
in
the
process
of
implementing
proper
cleanup
for
our
thread
as
a
whole,
let
alone
within
a
thread.
B
A
B
A
I'm
I'm
more
like
the
so,
for
example,
there's
a
wrap
function
right.
What,
if
we
you
know,
alternatives
are
something
like
a
new
wrap
function.
That
gives
you
a
tag
you
mean
it
returns
like
like
some
sort
of
unique
value.
Yeah
I
mean
basically
it
could
do
exactly
the
same
thing
as
the
current
tag
does
but
gives
you
basically,
when
you
wrap
here's.
B
B
Yes,
I
mean
okay,
we
can
implement
it.
You
know
you
like.
Do
you
want
a
new
type
or
do
you
want
an
old
type?
But
no?
No,
we
actually
can't
busy.
If
you
want
an
old
type,
then
which
one
do
you
want
right
so
pretty
much
the
add-on
has
to
say
you
know
you
know,
paint
it
with
this
color
sort
of
thing
you
know,
but
like
so,
for
example,
you
provide
a
constructor
right
that.
A
Yeah,
like
you,
could
you
could
because
I'm
trying
to
write
I,
don't
remember
the
interface,
all
the
interfaces
off
the
top
of
my
head?
But
but
you
are
the
way
the
async
wrap,
because
that's
where
they
see
where
the
wrapping
is
used
right,
wrapping
UNIP
wrapping,
something
which
then
you
create
instant
like
you
get
instances.
So
when
you
say
new
well,.
B
B
Yes,
yes
commonly
or
correctly
used,
it
is
a
fairly
fairly
strong
type
checking
man.
It
is
as
strong
as
any
types
of
picking
will
be
JavaScript.
So,
okay,
you
can
fool
instance
of
yes,
you
can
and
therefore
you
can
also
fool
late
on
the
native
side
right
so
yeah,
that's
the
contention.
Basically
right.
Okay,.
A
C
B
B
B
We
might
run
into
issues
with
with
inheritance
because
with
inheritance
you
know
it's
supposed
to
be
instance
of
so
it
better
not
fail.
Even
though
the
tag
is
mismatched,
because
it's
really
an
instance
of
a
subclass,
but
but
we
can
probably
handle
that
gracefully
and
and
and
correctly
but
yeah.
That's
a
that's
a
good
idea!
Yeah.
If
we
made
instance
of
stronger
for
for
for
use
on
the
native
side,
then
ready
okay,
yeah,
I,
I'm,
gonna,
I'm
gonna
work
with
that
and
see
if
I
can,
if
I
can
obviate
the
PR.
A
B
Okay,
there's:
okay,
there's
one
more
issue:
yep
the
the
constructor
address,
may
not
be
the
right
way
to
go.
We
may
need
both
the
constructor
address
and
the
data
pointer
that
is
being
passed
to
not
be
defined
class
because
it
may
be
a
class
Factory,
in
which
case,
in
which
case
the
constructor
address,
is
really
supposed
to
be
dynamic
right
right.
B
So
but
of
course
it
cannot
be
dynamic
on
the
native
side,
because
you
cannot
just
create
functions
on
the
fly
like
native
functions,
not
without
FFI
right,
so
we
need
more
than
that,
we
probably
need
we
need
the
constructor
pointer
and
the
void
star
that
was
passed
in
and
then
and
then
for
a
strong
instance
of
yeah
for
a
strong
instance
of
check.
Yes,
the
instance
would
have
to
bear
those
two
marks,
basically
in
order.
So
what's
the
tag
doing
today,
that's
that's
what
it's
doing.
B
A
B
Yeah
yeah,
yeah,
okay,
but
I
think
I
think
those
who
do
I
work
with
factories.
They
are
already
aware
of
this
because
they
are
the
ones
who
rely
on
the
data
pointer.
So
so
so
they
are
they're
familiar
with
the
workflow,
so
I
don't
think
we
need
to
emphasize
too
much
no
more
than
we
need
to
emphasize
the
importance
of
the
void
star
pointer
at
all
right,
I,
just
I,
just
thought
of
I
just
thought
of
one
thing,
which
is
that
I
don't
know
if
we
can
do
this
entirely
behind
the
scenes,
because.
B
Because
you
know
we
we
have,
we
have
nappy
new
instance
right.
So
if
you
say
nappy
new
instance
you
pass
in
the
constructor,
then
the
constructor
is
just
a
nappy
value
and,
and
the
constructor
may
or
may
not
have
like
at
the
function
point
are
stored
inside,
because
the
because
you
know
you
may
be
constructing
an
instance
for
a
class
that
you
didn't
define
using
that
be
defined
class.
You
know
the
constructor
may
be
coming
in
from
JavaScript
and
it
may
just
be
appearing
your
JavaScript
constructor
yeah
right.
B
So
so
you
you,
don't
really
get
an
opportunity
to
retrieve
the
the
the
this
function
pointer
and
the
void
star.
You
know
you
would
have
to
receive
it
explicitly
so
so
I,
don't
I,
don't
think
we
can
do
this
behind
the
scenes
like
we
can't
do
it
without
the
new
API.
What
we
can
do
behind
the
scenes
is
we
can
augment
snappy
instance
of
week.
We
can
obviate
the
need
for
half
this
API
like
to
actually
perform
the
tagging.
You
need
to
perform
an
explicit
step
which
tags,
however,
the
the
stepped,
whereby
you
you
check.
A
B
Yeah
yeah,
that's
that's!
That's!
That's
an
alternative!
I've
considered
right,
like
yeah
cuz.
You
know
you
don't
want
to
call
into
an
API
too
often
right,
right
and
maybe
especially
if
you're
you
know
in
a
fairly
hot
chunk
of
code,
then
we
want
to
avoid
causing
through
an
API
as
much
as
possible,
so
so
yeah.
If
the.
B
I
floated
that
before,
but
I'm
floating
in
again,
because
now
this
this
idea
came
up
and
the
idea
that
you
can
attach
multiple
independent
pointers
is
is
basically
sort
of
a
side
effect
of
the
type
tagging
you
know
and
and
and
and
this
time
we're
introducing
it
because
of
the
type
tagging,
not
because
we
want
to
be
able
to
attach
multiple
pointers
right.
So
the
argument
has
sort
of
flipped,
but
but
the
type
tagging
enables
multiple
pointers
by
default
right.
So
we
might
as
well,
you
know,
get
that
one
yeah
instead
of
multi.
A
B
A
Things
the
answer
is
I
mean
my
mind
is
if
this
is
a
real
problem
shouldn't
we
be
like
saying:
well,
here's
the
new
way
to
do
it.
You
know
here's
the
new
parameters,
everybody
should
be
passing
us
enough,
so
it
can
be
properly
wrapped
and
interesting
instance
of
this
stronger
or
is
there
like
an
overhead
cost
reason
why
you
wouldn't
do
that.
A
Like
should
we
have
a
new
wrap,
which
is
now
the
one
we
want
everybody
to
use
persons
calling
a
tie
graph.
This
is
just
like
you
know
when
you're
wrapping,
you
should
wrap
in
this
way
and
we
should
have
tagged.
Maybe
we
should
have
tagged
it
from
the
beginning,
but
we
forgot
to
so
now.
We're
gonna.
You
know
we're
not
gonna
delete
the
old
one,
but
we're
adding
a
new
one
that
lets
you.
Do
it
better.
Oh
yeah.
A
B
Yeah
yeah
yeah
I
mean
if
it
turns
out
that
rapping
rapping
and
ensuring
the
integrity
or
ensuring
the
type
of
the
pointer
is
the
only
reason
or
are
the
overwhelming
reason
for
doing
the
attacking.
If
that
is
the
case,
then
yes,
then
we'd
want
to
we'd
want
to
come
up
with
a
new
new
version
of
rap
yeah.
So
the
only
what
the
only
reason
why
we
would
separate
it
into
two
two
operations
want
to
rap.
B
One
to
tag
is
if
you've
tagged,
for
other
reasons
too
right,
you
know,
but
if
it
turns
out
that
that's
not
really
often
the
case,
then
then
yeah
we
can
just
come
up
with
a
new
type
of
rap
right,
yeah.
So
and
that's
that's
in
there,
so
so
so
so
this
thought
is
in
there
and
yeah
so
yeah
we
just
need
to.
We
just
need
to
sort
of
Mull
it
over
some
more
yeah.
A
B
B
So
so
so
Ana
Ana
pointed
this
out
and,
and
it
was,
it
was
quite
shocking
to
me,
and
so
so
you
know,
as
part
of
the
ongoing
saga
of
of
you
know,
tearing
things
down
correctly
now
that
we
have
worker
threads
I
I
started
working
on
on
basically
rendering
all
of
these
finalized
errs,
as
as
environment
cleanup
hooks
just
to
see
if
it
would
work
right,
right
and
and
it
becomes
an
intricate
dance
right,
because
you
know
why
are
you
tearing
down
this
object?
Is
it
because
the
environment
is
going
down?
B
B
Yes,
I
mean
I
mean
ultimately,
ultimately,
we
have
all
the
tools
and
and
a
Down
maintained
errs,
have
all
the
tools
for
cleaning
up
because
they
could
just
do.
You
know
cleanup
hooks,
but
you
know
right,
it
is.
It
is
quite
an
intricate
dance
and
if
we,
if
we
have
them
all,
do
this
dance,
then
they're
never
going
to
be
in
sync
and
there's
always
going
to
be
bugs
somewhere,
but
on
the
other
hand,
I'm
not
sure.
B
If
we
can
simply
just
you
know,
take
all
the
finalized
errs
and
stick
them
as
into
it,
the
environment,
hooks
list
and
then
just
hope
for
the
best.
You
know
that
that
may
be
that
that
may
not
that
that
may
not
be
something
we
can
do,
but
since
we've
never
done
it,
we
have
to
see.
We
really
want
is
a
finalized
on
exit.
B
Well
idea
that
you
would
tell
the
engine:
listen.
Buddy
garbage
collect
one
last
time
clean
up
properly
after
yourself,
because
you
have
all
these.
You
know
native
pointers
hanging
around
and
you
know
you
may
want
to
clean
that
up,
but
I
forget
now
what
they
were.
But
Ana
mentioned
two
very
good
reasons.
B
This
is
not
possible,
oh
yeah,
it's
because
it's
because
well
she
said
that
on
the
one
hand,
the
the
engine
gets
torn
down
after
the
note
environment
has
already
been
torn
down,
at
which
time
napi
is
no
longer
usable
anyway,
because
there
is
no
more
note
environment
and
and
a
second
of
all,
even
if
that
were
not
the
case.
She
had
a
second
reason
for
that,
like
even
if
we
were
to
flip
it,
where
you
tear
down
the
engine
first
and
then
the
note
environment
did
she
had
an
argument
for
that
one
too.
B
So
so,
basically,
she
was
saying
that
that
asking
the
engine
to
garbage
collect
everything
is
not
an
option.
So
so
this
is
where
we
are
now
and
I'm
gonna
see
if
we
can
do
it,
if
we
can
do
it
by
just
simply,
you
know
adding
an
environment
cleanup
hook
for
everything
and
because
the
other,
the
other
concern
is,
will
this
perform
right?
Yeah,
because
you
know
the
environment
clean
up
hooks,
there
I
think
ultimately,
they're
they're
stored
in
a
set
which
is
which
is
I.
B
Hook
for
everything,
don't
you
want
one
cleanup
puck
which
it
doesn't
matter
in
the
end
right,
because
because
what
what
are
we
going
to
end
up
doing
we're
gonna
end
up
storing
it
on
the
environment
right
and
then
we're
gonna
have
a
set
of
these
finalized
errs
on
the
environment?
So
it
I,
don't
think
it's
any
heavier.
If
if
we
store
it
and
then
we
give
one
cleanup
hook
versus.
C
B
C
B
Yes,
but
but
if
we
don't
use
cleanup
books,
if
we
only
use
one
cleanup,
if
you
still
have
to
get
rid
of
that
sure,
I
mean
I,
guess
so,
there's
a
remove
cleanup
hook
as
well.
Yeah
yeah
there
is,
there
is
yeah
yeah.
So
it's
it's
exactly
the
same
as
a
finalizer.
Only
now
you
know
it's
a
it's
a
it's
a
cleanup
hook
right,
okay,.
B
And
they're
going
to
balloon
greatly
now
so
so
you
know
the
question
is:
can
can
can
the
implementation
handle?
You
know
right,
I
mean
the
cleanup.
Hooks
will
be
significantly
there
exactly
that's
right,
because
every
every
rap
JavaScript
object
is
not
gonna
have
a
cleanup
hook
and
it's
gonna
have
a
finalizer.
So
it's
gonna
have
two
things
attached,
one
to
the
environment
and
one
to
the
engine
right.
B
Otherwise
it
already.
We
already
have
the
finalizar
right,
though
yeah,
but
the
finalizer
never
gets
called
right
because
because
it
only
gets
called
if
the,
if
there's
a
garbage
collect
ass
after
the
object
has
gone
out
of
out
of
scope
right,
oh
well,
you
mean
at
the
shutdown
time,
there's
gonna
be
more
overhead
like
yes,
but
there's
also
going
to
be
overhead
during
runtime.
To
to
no
add
hooks,
remove
hooks,
add
hooks,
remove
hooks.
You
know,
because
if
the
finalizar
does
get
called,
then
you
have
to
remove
the
corresponding
cleanup
hook
right.
B
A
B
B
B
A
Yeah
and
I'm
just
trying
to
think
what
are
there
any
other
optimizes.
So
yes,
main
thread
is
one
we
should
optimize
for
and
then
is
there
anything
else
that
it's
kind
of
like
you
know
another
option.
So
here's
the
this
is
the
you
know
these
finalized
errs
are
mostly
there
because
you
have
native
natively
allocated
memory
right.
Yes,
so
if
we
provided
I'm
just
thinking
top
ahead,
if
we
provided
an
allocator
that
basically
said
here's
memory,
you
use
this
allocator
and
at
the
end,
we're
just
gonna
free
all.
B
B
I,
don't
know
I
bet,
that's
the
impression
I'm
getting
right,
because
you
know
they
I
mean
that's
what
that's
what
v8
does
to
it?
The
test
support
for
like
specifying
the
alligator
and
and
and
so
on,
and
so
forth,
just
to
work
in
as
many
environments
as
possible,
like
yeah
yeah,
you
could
do
it
this
way
right
and
you
know
we
could
solve
this
with
documentation
alone.
You
know
we
could
say
you
know
for
for
proper
multi-threaded.
B
You
know
another
insight
we've
had
in
our
in
our
path
towards
towards
worker
threads
is
not
only
that
you
know
don't
store
stuff
in
global
static
variables,
but
also
that
you
know
the
the
things
that
you
wrap
may
never
be
de-allocated
unless
you
also
have
a
cleanup
hook,
and
so
so
you
know
stuff
that
is
left
over
at
when
the
cleanup
hook
gets
called.
You
should
free
at
that
time.
Otherwise
people
will
file
bugs
saying
your
module
is
leaking
memory
right.
A
So
that's
definitely
good
documentation
right.
So
if
that
was
enough,
then
there
we
go
right,
but
the
issue
is:
is
that
we're
talking
about
performance
and
like
okay?
So
we
can?
If
you're
gonna
say
that,
then
you
know
it
doesn't
sound
like
it
sounds
like
we
should
potentially
just
have
something
which
you'll
add
the
hooks
for
you
right,
because
otherwise
everybody
has
to
figure
out
the
problem
themselves.
A
B
A
B
So
you
know
if
we
just
bunch
up
all
these
finalizer
x'
and
call
them,
then
then
you
know
we
may
mess
up
the
memory
because
we
free
things
in
the
wrong
order
or
whatever,
but
on
the
other
hand,
because
they
are
finalized,
errs
and
and
because
they're
there
their
semantics
are
hey.
This
could
get
called
any
time.
Yeah.
E
B
It
couldn't
get
called
at
all
then
right.
I
would
think
that
that
that
their
usage
in
itself
would
would
mean
that
that
you
know
had
on
maintainer
czar
prepared
to
have
these
things
executed
in
any
order
whatsoever.
So
it
may
actually
be
okay
because
they
are
finalized,
errs
to
to
just
bunch
them
up
and
call
them
yeah.