Mark H Weaver writes:
> Finalizers are a huge can of worms. I suspect this is why Ludovic was
> encouraging you to avoid them entirely, but I agree that we need to
> find a way to make them work for when they are needed.
Again, LilyPond does not really have an option to avoid finalizers
(free_s
David Kastrup writes:
> Since LilyPond relies on C++ data structures and containers for its
> operation and those are also involved in the mark walks, "can be called
> on arbitrary garbage"
Who are you quoting here?
> But the mark-on-general-garbage problem seems sort of system-immanent to
> co
Mark H Weaver writes:
[...]
The race-condition related patch suggestions have been submitted to
LilyPond's tracker.
Tracker issue: 4304 (http://code.google.com/p/lilypond/issues/detail?id=4304)
Rietveld issue: 210810043 (https://codereview.appspot.com/210810043)
Issue description:
Smob code c
Mark H Weaver writes:
> Hi David,
>
> Thank you for the minimal test case. This is enormously helpful.
>
> David Kastrup writes:
>
>> The symptom likely occurs when an object is collected and consequently
>> its free_smob function gets called.
>
> After some investigation, I believe I've confir
Hi David,
Thank you for the minimal test case. This is enormously helpful.
David Kastrup writes:
> The symptom likely occurs when an object is collected and consequently
> its free_smob function gets called.
After some investigation, I believe I've confirmed that this is exactly
what's happen
This precludes porting LilyPond to Guile 2 since LilyPond relies
extensively on the mark_smob functionality.
The symptom likely occurs when an object is collected and consequently
its free_smob function gets called. This free_smob function essentially
is responsible for freeing all resources cla
