Re: Rational

[Hans Åberg]

> On 23 May 2018, at 00:41, David Kastrup <address@hidden> wrote:
> 
> Hans Åberg <address@hidden> writes:
> 
>>> On 22 May 2018, at 23:28, David Kastrup <address@hidden> wrote:
>>> 
>>> Hans Åberg <address@hidden> writes:
>>> 
>>>>>> I wrote a C++ wrap for that latter, too. As it turns out to be
>>>>>> difficult to keep of pointers into the GC heap, I had to use only
>>>>>> those that it supplies. Do you do that?
>>>>> 
>>>>> I don't know what "I had to use only those that it supplies" is supposed
>>>>> to mean, so I cannot answer the question.
>>>> 
>>>> In addition to the collected GC_malloc, there are
>>>> GC_malloc_uncollectable and GC_free that correspond to malloc and
>>>> free. If one uses the latter pair and have pointers into the GC heap,
>>>> they may suddenly disappear, causing strange memory errors.
>>> 
>>> That's why we don't do that.
>>> 
>>>> In addition, beware that on some platforms, the GC must be initialized
>>>> before the first use (like on MacOS), and if one is using global C++
>>>> objects with heap allocations, that must occur before those being
>>>> initialized, which is before 'main' starts.
>>> 
>>> Uhm, you _are_ aware that LilyPond has been used for large scores with
>>> Guile data structures for 20+ years?  Don't you think people might have
>>> noticed a problem in the mean time?  If you want to contribute useful
>>> advice, it might be a good idea to actually look into the LilyPond code
>>> base.  The vast majority of LilyPond's memory management in connection
>>> with Guile is in lily/include/smobs.hh and lily/include/smobs.tcc .
>> 
>> So you don't know anything about the Boehm GC?
> 
> Is there a point to this silliness?
> 
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19883>
> 
> Apparently I got to know enough to distill a test case showing that
> Guilev2's type system was critically affected by a bug in the Boehm GC's
> use of finalizers, leading to workarounds first in the LilyPond code
> base and later on in Guile proper.

Relative to that, which seems to be a problem with dead, collected pointers, if 
one is using what I said above, then the GC keeps those objects pointed at 
alive.