Re: Mark procedures and LilyPond

[Hans Åberg]

> On 6 Nov 2015, at 13:32, Mark H Weaver <address@hidden> wrote:

>> We should fix Guile so to "null out" the SMOB typecode when the SMOB
>> finalizer is called.  If our mark procedure sees a SMOB that has already
>> been finalized, it just returns.
> 
> Unfortunately, I doubt this will be sufficient for LilyPond.  The small
> example case in <http://bugs.gnu.org/19883>, which is apparently
> representative of how things are typically done in LilyPond, has
> structures like this:
> 
>                   __________                    __________
>  Objects in      |          |                  |          |
>  GC-managed      |  SMOB 1  |                  |  SMOB 2  |
>     heap         |__________|                  |__________|
>                     |   ^                         |   ^
> .....................|...|.........................|...|..........
>                   __v___|___      _________     __v___|___
>  Objects in      |          |    |   STL   |   |          |
>  normal heap     |C++ object|--->|container|-->|C++ object|
>  (not scanned    |__________|    |_________|   |__________|
>     by GC)
> 
> 
> The SMOB finalizers free the associated C++ objects below them.  Now,
> suppose that none of the objects above are reachable, so both SMOBs are
> queued for finalization.  Now suppose that SMOB 2 is finalized first,
> thus freeing the C++ object below it.  Suppose further that we null out
> the SMOB 2 typecode.
> 
> Now another GC occurs and the marker is called on SMOB 1.  It's typecode
> has not yet been nulled, so the user-specified mark procedure is called.
> The mark procedure for SMOB 1 iterates over the STL container, and for
> each C++ object within, marks the corresponding SMOB via the upward
> pointer, in this case SMOB 2.  Although SMOB 2's typecode has been
> zeroed out, the discovery of the fact is too late, because the (freed)
> C++ object below it has been referenced.
> 
> As far as I can tell, this way of doing things depends on the old 1.8 GC
> finalization semantics, where all of the finalizers are called before
> the mutator resumes execution.

Is Guile 2 doing its own finalization, not synced withe the Boehm GC?