Re: [PATCH] Marking weak alist vectors

[Ludovic Courtès]

Hi Marius,

Marius Vollmer <address@hidden> writes:

> I still have to read your patch carefully, but just from your
> description of the problem, I would say that nothing is actually
> wrong.  We don't make any guarantees about the sequence in which
> objects are 'freed' that are unreachable.
>
> This should only matter for smobs with their user written FREE
> procedures.  The manual says:

[About SMOBs' being freed]

The relevant part of the manual with respect to this issue is the
following (in node `Weak References'):

     Weak references let you attach bookkeeping information to data so
  that the additional information automatically disappears when the
  original data is no longer in use and gets garbage collected. In a weak
  key hash, the hash entry for that key disappears as soon as the key is
  no longer referenced from anywhere else.

Likewise (in `Object Properties'):

     Internally, object properties are implemented using a weak key hash
  table.  This means that, as long as a Scheme value with property values
  is protected from garbage collection, its property values are also
  protected.  When the Scheme value is collected, its entry in the
  property table is removed and so the (ex-) property values are no longer
  protected by the table.

IOW, property values are to be "collected" _after_ the Scheme value to
which they are attached has been collected.  Admittedly, the manual is
quite fuzzy as to whether "after" means "during the next round of
mark/sweep" or "maybe during the same round of mark/sweep but at least
property values are swept after the Scheme value has been swept".

In any case, if a value P is attached as a property of some object O,
then O should be "collected" _before_ P.  In practice, if both O and P
are SMOBs, then this means that O should be "freed" before P.

Please, have a look at the `test-weaks.c' file I posted.  It attaches
SMOBs as properties of other SMOBs.  And it's maybe clearer than long
explanations.  ;-)

Thanks,
Ludovic.