Re: Unmark for finalization and stuff

[Roberto Ierusalimschy <roberto@...>]

> One thing I couldn't quite express in my last mail is about the "remove key after finalization" and "remove value before finalization" behavior. For example, when a weak value is removed from a table before its finalization, so is the corresponding key (logically). But what if the key requires this entry to be removed after finalization?

If an object A requires an object B for its finalization, A clearly
should not keep B in weak-value table (otherwise B could/would be removed
much earlier).


> What is the rational for the removal behavior to have to be different
> for keys and values? Wouldn't it be ok for the values to removed
> later, too?

The rational is that, except when traversing a table, a key gives
you access to its value, but a value does not give you access to its
key.  So, if a key A is marked for finalization (and therefore not
accessible), the presence of a pair A->B in a table is "invisible" for
the program (except for traversals), so it is ok for A to be there. On
the other hand, if A is accessible, B is directly accessible too; it
would be weird to have an object marked for finalization directly
accessible by the program.


> I also found a bug maybe.
> In a table with weak keys and an entry in the form of a closure as the key with one of its captured values as the value (and neither reachable), the entry is removed before the finalizer is called. I guess that is not correct?
> Swap the key and value and it is removed afterwards.
> Did I miss something here?

You did. The object being finalized is the table, not the closure.  In
the first case, the key does not have a finalizer, so it is removed
immediately. In the second case it does, so it is removed only after
running its finalizer. (When the table is being finalized, it may need
to access the closure, if the weak table maps tables to closures. If
the map is from closures to tables, that entry is useless for the table
being finalized.)

-- Roberto