l...@gnu.org (Ludovic Courtès) writes: > David Kastrup <d...@gnu.org> skribis: > >> l...@gnu.org (Ludovic Courtès) writes: >> >>> Andy Wingo <wi...@pobox.com> 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
