lilypond-devel
[Top][All Lists]
Advanced

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

Re: smob design


From: David Kastrup
Subject: Re: smob design
Date: Tue, 07 Oct 2014 08:33:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Dan Eble <address@hidden> writes:

> The Smob code is sending me mixed messages.

Welcome to the club.

> On one hand, it looks like multiple levels of derivation will not
> work, e.g. creating a subclass of Book, because Book::Book() would
> call smobify_self() before the subclass constructor runs
> scm_gc_register_collectable_memory() would sizeof(Book) rather than
> sizeof(derived class) etc.?

Correct.  scm_gc_register_collectable_memory is advisory information for
the garbage collector, not crucial.  In this case, the advice is not
accurate.

> On the other hand, Book uses the macro VIRTUAL_COPY_CONSTRUCTOR to
> define a virtual clone() method, as if derivation were intended.
>
> Am I confused because the code is confusing, or for no particular
> reason?  If the code could be cleaned up, which direction should it
> move in?

This is the cleaned-up version.  The warts were covered in mud before.

At the current point of time, the most necessary cleanup is getting
lifetime issues covered.  While the current master still has a
PostScript backend problem, you can reliably crash it before the output
stage by using GUILEv2 (./autogen --with-guile2)

out/bin/lilypond input/regression/divisi-staves.ly

It turns out that of all hare-brained memory protection schemes I've
looked at so far (there may be worse stuff to come) system.cc takes the
cake, and I suspect that to be involved with the GC crashes in
divisi-staves.ly.

You'll see that GC is enabled before System is actually initialized.
Grob_array *all_elements_ gets protected by giving it a name
"all-elements" and sticking it into the property list of Spanner.  Then
the constructor completes after which derived_mark takes over and
protects the elements of all_elements_.  Because Grob_array elements are
not generally protected but only via System's own mechanism.

Now try figuring out what happens during "suicide" in which order.  What
happens with potentially cross-staff material, like stems having a
Grob_array of note heads?

Note that making Grob_array protect its childs (there is a #if to that
purpose) moves the location of the crash but not terribly so.

-- 
David Kastrup



reply via email to

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