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 function
>> was called on an object after
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. Note that
> 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 sufficient for LilyPond
>____
> Objects in | | | |
> GC-managed | SMOB 1 | | SMOB 2 |
> heap |__| |__|
> | ^
d|__||_| |__|
> 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. I can’t imagi
er/why it was considered unfit.
>
> I agree with you that the patch there looks reasonable to me too, though
> AFAIU the original code should work just fine too.
>
> There area few things at play.
>
> (1) A bug related to SMOB finalization and marking that affects
> LilyP
ferent things around
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,
Andy Wingo skribis:
> Some of the points I made have not been made before, AFAIK. The point
> about marking occuring concurrently with the mutator even in the absence
> of threads, for example.
Yes, right.
>> I agree with you that we must keep recommending against using [mar
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 mutator even
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, but
Hi Andy,
Thanks for the detailed analysis of the problems with mark procedures.
Andy Wingo 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 would need good arguments fo
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 l
rday: mark 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 con
13 matches
Mail list logo
