[Top][All Lists]

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

Re: Rational

From: David Kastrup
Subject: Re: Rational
Date: Wed, 23 May 2018 10:39:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Hans Åberg <address@hidden> writes:

>> 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?
>> <>
>> 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.

How come all of those smart guys knowing better than myself how LilyPond
works and how garbage collection works and how C++ works can never be
seen creating a single patch but instead have to rely on telling some
simpleton like myself how he should be doing things?

Seriously folks, if you think you are so much more intelligent, get to
work rather than bother lecturing a moron like myself.

David Kastrup

reply via email to

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