Re: [PATCH] Marking weak alist vectors

[Ludovic Courtès]

Marius Vollmer <address@hidden> writes:

> C code can observe the GC doing its thing (via the smob free
> functions).  In order not to overconstrain the implementation of the
> GC (which is pretty constrained already anyway), we have the
> additional rule that there is no guarantee about the order in which
> objects are swept during the sweep phase.

Relaxing such constraints may work for Scheme objects that are entirely
under Guile's control, but it certainly isn't acceptable when SMOBs come
into play: SMOBs _will_ from time to time be victims of this, resulting
in double-frees and the likes.

SMOBs shouldn't ever have the impression that a value attached to a weak
key is freed _before_ that weak key.  From the SMOB programmer viewpoint
that is really an error, no matter if it's "before but during the same
phase" or not.

> Why do you need this guarantee?

For a concrete example, you may want to look at `test-weaks.c' which I
posted when this discussion started, i.e. a long time ago.  ;-)

For a more general example where this is an issue:
http://lists.nongnu.org/archive/html/g-wrap-dev/2005-09/msg00006.html
(see at the bottom).

> (If you really need this feature, I will start talking you into using
> guardians to enforce some order on finalization.)

I hadn't look into this so far, and indeed, that looks interesting!
That's a nice reflexive approach to GC.

I don't think it solves my very problem though.

>> In any case, if a value P is attached as a property of some object O,
>> then O should be "collected" _before_ P.
>
> Why? Isn't it enough to say 'P is not collected before O is unreachable'?

If user-definable objects (SMOBs) didn't exist, that would be perfectly
fine.  But the mere existence of SMOBs prevents such optimizations.

Why would we like to retain such sloppy semantics which are problematic
to the C (SMOB) programmer?

Thanks,
Ludovic.