[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 18:12:54 +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 16:15, David Kastrup <address@hidden> wrote:
>> Hans Åberg <address@hidden> writes:
>>>> On 23 May 2018, at 15:46, David Kastrup <address@hidden> wrote:
>>>> Try actually reading the code.  lily/include/smobs* are not that many
>>>> files and nowadays pretty exclusively encapsulate all Scheme-related
>>>> memory management.
>>> As long you don't have pointers into that, as you suggested with
>>> Rational and other data that uses it.
>> Look, you are just stabbing around in the dark here.  Quite a few of
>> your statements don't even make sense.  You need to get yourself
>> acquainted with the code if you want to get anywhere.  Rational is not a
>> structure containing garbage-collected elements or pointers.
> The thread started with suggestions for changing that.


>> It's fixed-size which is what triggered the original poster's
>> complaints.  Changing that requires work since currently you can use
>> and store Rational everywhere without bothering about garbage
>> collection.  I know perfectly well that the premise of the Boehm GC
>> is that you can do that with SCM values anyway but the cost
>> associated with that is a vastly expanded seed area for the mark pass
>> of garbage collection, basically adding the complete heap.
> 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 the
equivalent of GC_malloc_uncollectable.

> And I found no reference to it in LilyPond, so I got curious about how
> you do it. But you are not going to tell me, so forget about it.

You know, if you actually bothered _asking_, you'd increase your chances
of getting an answer.

>> LilyPond's data structures are too much of a
>> mixed bag to make that a good idea.
> It is indeed slower, but not using it requires isolating it. But is of
> course fine that you are willing to do that.

Sigh.  It's been done for dozens of years already since Guilev1 required

David Kastrup

reply via email to

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