guile-user
[Top][All Lists]
Advanced

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

Re: Guile foreign object interface


From: David Kastrup
Subject: Re: Guile foreign object interface
Date: Thu, 09 Mar 2017 00:00:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> David Kastrup <address@hidden> skribis:
>
>> address@hidden (Ludovic Courtès) writes:
>>
>>> Andy Wingo <address@hidden> skribis:
>>>
>>>> I am not so sure about about this one.  I think it's not accurate to
>>>> characterize beginning to replace a 25-year-old C API (SMOBs) as
>>>> "churn".
>>>
>>> I think the point is that there’s lots of code out there that rely on
>>> SMOBs and we shouldn’t break it overnight, precisely because that API
>>> is this old.
>>>
>>> Of course, I agree that pushing users towards an improved API is the
>>> right thing long term, no argument here.
>>
>> Shrug.  LilyPond has all of its SMOB usage condensed into few C++
>> classes, so it is comparatively easy to migrate to a different API as
>> long as it offers comparable functionality.
>>
>> Which it doesn't (namely the ability of marking objects reached through
>> STL-managed data structures).  So it's pretty pointless to "push users
>> towards an improved API" and hardly "the right thing".
>
> Thanks for your feedback, this is a kind of use case we’d like to
> support.
>
> I’m sure we already discussed it and then I forgot, but would anything
> prevent the use of specific C++ allocators in this case?  The STL data
> structures could be allocated on GC-scanned memory, in which case mark
> procedures are unneeded.

We are not talking about STL data structures containing SCM values but
data structures containing other data structures and pointers to other
data structures.  You cannot sensibly garbage collect when whole memory
areas in which allocation and deallocation is done are in GC-scanned
memory and there is no difference between data structures that have been
freed and data structures that haven't.

> If this cannot be done, there’s always the possibility of having a
> weak hash table to keep the C++ and Scheme object life cycles in sync.
> That happens even with C APIs that record a pointer to an object we
> care about in non-scanned memory.  Since 2.0 was out I’ve never used
> mark procedures for in C bindings.
>
> Thoughts?

LilyPond is a large-scale application which will eat up a significant
ratio of the available address space in 32 bit applications and will
process, in a documentation run, thousands of files with little overlap.
Already in Guile 1.8 where _only_ the stack is conservatively marked and
gc is called explicitly at known points of low-stack usage, we have
occasional false positives in garbage collection (the debugging runs
flag them).  With large memory areas being conservatively scanned, this
is going to get a whole lot worse.

The point of time where it makes sense to try to evaluate the impact or
feasibility of such functionality removals (and Boehm GC _does_ support
finalization) is when LilyPond is otherwise running fine on Guile 2.
With the current slowdown by a factor of 5-10 and a number of other
problems preventing the LilyPond test suite from running, there just
isn't any setup where a useful evaluation could take place.

As there is no technical necessity for planning the wreckage of existing
functionality when there hasn't even been a stable release containing
the prospective successor, I cannot see a viable point in raising yet
more hurdles for existing applications to migrate to Guile 2 rather than
bite the bullet and fork Guile 1.8 in order to actually have some
dependable functionality to base other work on.

> As an aside, please keep the tone friendly as is the norm on this
> mailing list.

Disagreement is not the same as unfriendliness.

-- 
David Kastrup




reply via email to

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