- **Patch**: countdown --> push
- **Comment**:
Patch counted down - please push
---
** [issues:#4997] Add Preinit class for early initialization**
**Status:** Started
**Created:** Sat Nov 12, 2016 10:03 PM UTC by David Kastrup
**Last Updated:** Tue Nov 15, 2016 11:27 AM UTC
**Owner:** David Kastrup
Add Preinit class for early initialization
This patch series may well be incomplete: strictly speaking, it might
be needed with Guile 1.8 already to ensure parts of derived classes
are not being scanned and interpreted by the mark_smob hooks before
they are initialized. However, the semi-asynchronous nature of
Guile 2.0 makes this situation more troubling.
I don't have positive proof that this code avoids actual crashes in
the context of either Guile 1.8 or Guile 2.0. While the
implementation is rather simple (and cannot be made much more
complicated since it has to work with objects in seriously incomplete
form), its necessity is headache-inducing. But if its necessity turns
out to be of more than theoretical nature, I'd rather have it in the
code base sooner than later. Probably some other derived classes than
those addressed in the followup patches should get the same treatment.
Here is the commit message for the first patch of the series, followed
by the others:
This is a tricky thing: once a base class calls smobify_self () in
its constructor, further allocations during construction of base
class and derived classes might lead to mark_smob calls on the
object under construction. When those call a virtual function like
derived_mark, the virtual function corresponding to the
incompletely initialized object is likely to be called.
This situation is acerbated in Guile 2.0 where the mark passes may occur
with only loose synchronization to the allocations.
The order of initialization of an object consists in calling the
constructors of virtual base classes, then of non-virtual base
classes, then initializing all data members.
As a result, the derived constructor comes too late for
initialization. That's where the Preinit template class comes in.
Derive from it _before_ deriving from the smobifying base class
providing derived_mark, and it will call its Base class' pre_init
function (which must not rely on the instantiation being complete).
The pre_init function should then put the derived class into a state
_before_ its constructor or a constructor of its data members is being
called where it's safe to call its derived_mark function. Note that in
particular that most STL data structures are in undefined state before
their constructor is being called, so the pre_init function has to
establish a state where derived_mark will not attempt to interpret data
members of types like std::vector which may not have been constructed
yet.
Use Preinit for Global_context, protect output definition
Use Preinit for font metrics
Use Preinit in Engraver_group
Use Preinit in Spanner
Use Preinit in Music
Use Preinit class in Scheme_engraver
This avoids calls of derived_mark on uninitialized data. Fold
Scheme_engraver::init_from_scheme (SCM) into converting constructor
since it has become identical to it.
http://codereview.appspot.com/316890043
---
Sent from sourceforge.net because testlilyissues-a...@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/testlilyissues/issues/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is
a mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
_______________________________________________
Testlilyissues-auto mailing list
testlilyissues-a...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
