[Top][All Lists]

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

Re: Guile foreign object interface

From: Ludovic Courtès
Subject: Re: Guile foreign object interface
Date: Thu, 09 Mar 2017 13:09:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

David Kastrup <address@hidden> skribis:

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

Not sure what you mean.

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

This sounds like speculation to me.  I don’t think we’ve seen slowdowns
when Guile then 1.9 switched to BDW-GC, quite the opposite.

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

LilyPond on Guile 2.0 is 5–10 times slower than on 1.8?

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

Note that SMOBs are still around in 2.2, not even deprecated, only

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

I agree.  However I found the tone of your messages patronizing and
aggressive, assuming bad faith and incompetence on the side of the Guile
developers (“planning for wreckage”, “pretty pointless”, etc. etc.)

This is not OK on the Guile mailing lists.


reply via email to

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