Re: Mark procedures

Andy Wingo skribis: > Picking up an old thread > > On Thu 05 Nov 2015 14:11, Andy Wingo writes: > >> (1) A bug related to SMOB finalization and marking that affects >> LilyPond >> >> For (1) it seems to me that we just have a bug. A SMOB mark

Re: Mark procedures

Picking up an old thread On Thu 05 Nov 2015 14:11, Andy Wingo writes: > (1) A bug related to SMOB finalization and marking that affects > LilyPond > > For (1) it seems to me that we just have a bug. A SMOB mark function > was called on an object after the finalizer.

Re: Mark procedures and LilyPond

> On 6 Nov 2015, at 13:32, Mark H Weaver wrote: >> We should fix Guile so to "null out" the SMOB typecode when the SMOB >> finalizer is called. If our mark procedure sees a SMOB that has already >> been finalized, it just returns. > > Unfortunately, I doubt this will be

Re: Mark procedures and LilyPond

object|--->|container|-->|C++ object| > (not scanned|__||_| |__| > by GC) Thanks for the picture, that’s very helpful! I still think we should be able to get rid of GC mark procedures in this case, sidestepping the bug you describe. This pattern is very common when writing bindings

Re: Mark procedures and LilyPond

that affects > LilyPond > > (2) The utility of mark procedures in general > > (3) The suitability of mark procedures for future uses > > (4) Whether we can get by without mark procedures, and if so, how. > > For (1) it seems to me that we just have a bug. A SMOB ma

Re: Mark procedures

g related to SMOB finalization and marking that affects > LilyPond > > (2) The utility of mark procedures in general > > (3) The suitability of mark procedures for future uses > > (4) Whether we can get by without mark procedures, and if so, how. > > For (1) it seem

Re: Mark procedures

On Thu 05 Nov 2015 11:29, l...@gnu.org (Ludovic Courtès) writes: > I think we all agree that mark procedures suck in many ways, so that’s > not the problem. :) Some of the points I made have not been made before, AFAIK. The point about marking occuring concurrently with the mutato

Re: Mark procedures

Hello! I think we all agree that mark procedures suck in many ways, so that’s not the problem. When I ported the old Guile to BDW-GC, I kept them mostly so existing code that uses SMOB can still work as expected. Of course, 90% of the time you could just remove them and things would work

Re: Mark procedures, LilyPond, and backward compatibility

finalizers and mark procedures, but we were ignorant; postulating retroactive omniscience doesn't help us make better decisions in the present. I also disagree very strongly that we are being irresponsible with respect to backward compatibility. We're doing what we can, and doing much more than most

Re: Mark procedures

Good post! I first like to second the need for our own gc. Regarding mark procedures. I prefer that we collect the use cases and make sure that the framework can handle them in a robust and effective way. I don't like to write mark procedures at all and your fixes seam to address quite a lot

Re: Mark procedures, LilyPond, and backward compatibility

Hi Andy, Thanks for the detailed analysis of the problems with mark procedures. Andy Wingo <wi...@pobox.com> writes: > At the end of our IRC conversation yesterday you put the burden on me to > argue against mark procedures, which was fair, but at this point I think > we

Mark procedures

procedures. To recap, since the ages of yore, Guile has allowed SMOB implementations to specify "mark procedures". Indeed in the olden days, these procedures were practically required, as the GC wouldn't otherwise trace any field of a SMOB. When we started using the BDW conservative colle