Re: [Gc] Two-phase finalization?

Paul Bone <[email protected]> writes:

> On Sun, Nov 08, 2015 at 12:28:14PM +0100, David Kastrup wrote:
>> 
>> Now the problem we encounter is that if some structure A points to B and
>> some structure B points to A and both A and B are placed into
>> finalization, then the finalization of A will delete the associated C++
>> structure.  If now a mark pass is allowed through B, it will try to
>> access the deleted C++ structure of A.
>
> The typical "solution" to breaking cycles for finalisation is to arrange
> objects differently.  I use "quotes" because this is more of a work-around,
> but I believe that it's the best solution anyone has proposed to the general
> problem (I don't know if this will be suitable for lillypond).
>
>     You have:
>
>         A* -> B*
>         ^     |
>         +-----+
>
>     (I use * to indicate that this object has a finalize.
>
>
>         A1*
>         ^
>         |
>         A -> B*
>         ^    |
>         +----+
>
> Now B can be finalised first, followed by A1.  So typically you would
> put the fields (like file descriptors) in A1 and the other fields in
> A.  I'm trying to imagine what this means for Lillypond, maybe they're
> glyphs for drawing notes or something...

Well, the problem with that approach is that "arrange objects
differently" is a whole lot of work given the current amount of objects,
and that work is not really incremental as you can expect crashes until
finished.

And that's just LilyPond: the documented semantics of the respective
Guile hooks don't match for other applications as well.  The main coping
strategy when brought up on the Guile developer list was an exuberant
call for not using mark hooks at all and making all memory GC-scanned.
However, I am less than enthused about that approach for an application
that can eat the majority of addressable memory with large chores (given
32-bit executables) when basically all memory is managed with
conservative garbage collection: I expect too many false positives then.
It's also somewhat tricky to change the manner in which standard C++
data structures provided by the STL libraries manage their allocations
and deallocations.

So I prefer to stick with the same code used with Guile 1 and instead
fix Guile 2 (or put workarounds into LilyPond to the same effect) to
actually have the same semantics as previously regarding the "free"
hooks.

I _think_ that the solution sketched in another mail (basically setting
Java collection semantics for bdwgc in combination with using
finalization for disabling the mark functionality on the destructed
objects) should be workable.  So I hope to have self-answered my
question.

> I realize this may not be helpful, it's not exactly the answer you
> asked for, and I can't begin to guess at how this would work for
> Lillypond.  However I would like to say that I LOVE the lillypond
> software.  I have a significant vision impairment and lillypond allows
> me to enlarge my sheet music (usually by typing it out again).  Thank
> you!

My mother has macula degeneration and has stopped playing the violin
because of being unable to sight read well enough.  I feel somewhat
guilty for not having worked out a solution for her.  But I don't really
see how I could keep up providing scores for her in parallel with the
other stuff I am doing.

-- 
David Kastrup