lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rational


From: Hans Åberg
Subject: Re: Rational
Date: Wed, 23 May 2018 19:11:58 +0200

> On 23 May 2018, at 18:58, David Kastrup <address@hidden> wrote:
> 
> Hans Åberg <address@hidden> writes:
> 
>>> On 23 May 2018, at 18:36, David Kastrup <address@hidden> wrote:
>>> 
>>> Hans Åberg <address@hidden> writes:
>>> 
>>>>> On 23 May 2018, at 18:12, David Kastrup <address@hidden> wrote:
>>>>> 
>>>>> Hans Åberg <address@hidden> writes:
>>>>> 
>>>>>> I ended up using GC_malloc_uncollectable, because it turned out too
>>>>>> tricky to use malloc.
>>>>> 
>>>>> This is C++, so we basically end up with operator ::new and operator
>>>>> ::delete unless overriden by individual classes.  They use
>>>> 
>>>> This what they suggest for the Boehm GC, and it is what caused
>>>> problems in my program.
>>> 
>>> Likely because of the expectation that it would be managed by the Boehm
>>> GC.  The Guilev2 documentation states:
>>> 
>>>      For memory that is not associated with a Scheme object, you can
>>>   use ‘scm_malloc’ instead of ‘malloc’.  Like ‘scm_gc_malloc’, it will
>>>   either return a valid pointer or signal an error.  However, it will
>>>   not assume that the new memory block can be freed by a garbage
>>>   collection.  The memory must be explicitly freed with ‘free’.
>>> 
>>> So memory allocated with the standard allocator in a Guile application
>>> is not managed by the Boehm GC.
>> 
>> The object has a container with GC objects, so using using standard
>> allocation for the container causes the GC to not trace the objects in
>> the container, and will thus collect them.
> 
> If you bothered looking at the LilyPond code base, you'll find that _no_
> STL containers are created containing SCM objects in the expectation
> that they will automagically marked for garbage collection.  Any STL
> container containing SCM objects is either locally used for existing SCM
> objects protected elsewhere, or its containing object is SCM controlled
> and uses mark hooks for marking the elements of the STL container during
> garbage collection scans.  There are even mechanisms for making sure
> that the STL containers are fully initialized before a derived class may
> have its mark hook triggered.

But scm_malloc does not use GC_malloc_uncollectable, it seems, so it too would 
require explicit markups in order to get internally in Guile.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]