Re: out-of-order GC

[Marius Vollmer]

Egil Moeller <address@hidden> writes:

> >    Fortunately, resource smobs can check, in their free functions,
> >    whether this has happened, by looking at the SCM_TYP16 of their
> >    reference to the display smob.  If the display smob is still valid,
> >    this will be scm_tc16_xdisplay, and the relevant X resource should
> >    be freed as normal.  If the display smob has been freed earlier in
> >    this sweep, GC will have set its SCM_TYP16 to scm_tc_free_cell;
> >    this indicates that XCloseDisplay has already been called, and so
> >    the relevant X resource no longer needs to be freed. */
> 
> Aha, so that's how it should be done.

Hmm. I think it would be better not to rely on this detail of how the
GC works.  I don't think we want to guarantee that you can always tell
whether a particular cell has been freed during this GC.  For example,
we might change the GC so that it gives heap segments back to the OS
when all their cells are on a freelist.  These cells are then `off
limits' to the application.  Or the GC might play tricks with the MMU
and make free cells write-only...

You could simply use scm_tc_free_cell anyway, being prepared to find a
new solution when your hack stops working, or you could add a
reference count to the C connection struct and point directly to it
from the C transaction object.  The connection could then stay around
long enough.  There are probably other solutions as well.

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