Re: Almost, but not quite: C++ STL in LilyPond

[Hans Åberg]

> On 5 May 2020, at 18:57, David Kastrup <address@hidden> wrote:
> 
> Hans Åberg <address@hidden> writes:
> 
>>> On 5 May 2020, at 17:09, David Kastrup <address@hidden> wrote:
>>> 
>>> One reason is that we want to get rid of finalisers particularly in
>>> connection with the Boehm GC.  Finalisers are called when garbage is
>>> collected, the collection of garbage is typically indicative of the
>>> expected lifetime of our objects (there are a few that might be
>>> unambiguously dead before), and thus it will cause C++ destructors to be
>>> called.  And those trigger, among other things, the deallocation of
>>> memory resources, but we'd rather want the deallocation to be determined
>>> by Scheme mechanisms and not have any resources in need of destruction
>>> other than falling into oblivion.
>> 
>> For the GC objects, I use operator new/delete with an extra argument,
>> the latter with empty body, wrapped in structure similar to
>> std:shared_ptr. Then the memory resources of those objects are only
>> handled by the GC, regardless of finalizers.
> 
> That does not sound like it has anything to do with SCM garbage
> collection.  

Sorry, I sent the message by mistake: I thought I clicked “Delete”, but it was 
“Send”, so if you so like, just forget about it.

> Nor is it phrased in a manner where I would understand what
> you are talking about.  It is not clear what a "GC object" is supposed
> to be, it is not clear what "I use" is supposed to mean with regard to
> where and how it is being used, "operator new/delete with an extra
> argument, the latter with empty body" presumably means that operator
> delete rather than the extra argument have an empty body.  It is not
> clear what it is supposed to buy us if operator delete has an empty body
> when calling operator delete is something triggered by the destructor
> and not having to call the destructor is a prerequisite for the life
> time being determined by garbage collection without finalisation hook.

C++ operator new/delete are called in pairs, so if the GC allocated objects 
have a pair of their own, then one can set a no-op delete.

> It is not clear _what_ is "wrapped in structure similar to
> std:shared_ptr" and how that is supposed to interact with Scheme.

This class use reference counting; instead use the GC allocating operator new. 
Don’t know about the Scheme part, though, but it uses something similar, I 
think.

>>> I've tried to come up with a clever callback scheme where the first
>>> use of a structure causes fake nodes to be created with a "Pointer"
>>> type that actually calls back with its address to its caller that
>>> then constructs a layout of SCM elements within its governed class.
>>> However, I have found no way to make this "parallel construction"
>>> where I could then swap out this specific "Pointer" behavior for
>>> regular SCM.
>> 
>> Similarly, it is necessary to call GC_INIT() on the first use on
>> MacOS, which can happen before ‘main’ is called. So for that, I let
>> operator new/delete call a function pointer which on the first call
>> initializes, and also changes the pointer to the ordinary function
>> pointer on future calls.
> 
> The ordinary function pointer.  I see.

Right. GC_malloc and GC_malloc_uncollectable.