Re: [PATCH] Marking weak alist vectors

[Marius Vollmer]

address@hidden (Ludovic Courtès) writes:

> 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.

Yes, SMOBs could profit from a guarantee about the order of
finalization, but I don't think that guarantee can be implemented
cheaply enough.  (Or can it?)

So, my current point of view is that smobs have to suffer in order to
make live easier for the GC.

> SMOBs shouldn't ever have the impression that a value attached to a weak
> key is freed _before_ that weak key.

This would not only apply to weak keys etc, but to all kinds of
references, right?  I.e., all SCM values belonging to a smob would be
guaranteed to be valid when the free function for that smob is called.
Thus, we are not only talking about your patch for weak hash tables,
but about big changes to the GC in general, right?

>> 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.  ;-)

Heh, that is not an example, that is a test case. :-)

> 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).

(I only read the article you linked to directly, not the thread.)

So you have a C API that requires a certain order for freeing objects
and that order needs to be honored by the smobs that wrap the objects,
right?

My immediate reaction is to suggest to fix this by layering something
on top of the C API, such as the reference counting that you mention
in your article.  (Refcounting is acceptable since cycles must be
prevented anyway.)

I agree that it would be nice to have Guile help with that, if only by
providing proven example code.

>> (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.

Yeah, you might be right...

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

Because we would need to change the GC significantly... that's the
only reason I can think of.

But note that the thing we are talking about now is very different
from what you started out with: now we are not talking about in which
run of the GC a value belonging to a weak key is collected (i.e., the
key in run n, the value in run n+1), but in what order objects are
finalized within a single run of the GC (if I am not confused now).

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405