Re: [Lilypond-auto] Issue 4357 in lilypond: Patch: Redesign listeners using templates

[lilypond]

Updates:
        Labels: -Patch-countdown Patch-needs_work

Comment #17 on issue 4357 by address@hidden: Patch: Redesign listeners using  
templates
https://code.google.com/p/lilypond/issues/detail?id=4357

> Updates:
>         Labels: -Patch-review Patch-countdown

> Comment #16 on issue 4357 by pkx166h: Patch: Redesign listeners using
> templates
> https://code.google.com/p/lilypond/issues/detail?id=4357

> David,  I tried to re-test this with patchy but it doesn't.  apply now
> (needs a rebase I suspect).

Pretty heavy rebase, yeah.  I did that but my followup patch again
refuses to work.  I figured out then that I use Scheme data structures
before they are known to GUILE and its behavior for this obvious error
case is not to trigger an abort with a helpful error message but rather
crash mysteriously during garbage collection.

So after figuring out that, I split off the Scheme initialization to a
separate mechanism and after debugging another day I learnt the hard way
why our current initialization in lily/guile-init.cc does

typedef void (*Void_fptr) ();
vector<Void_fptr> *scm_init_funcs_;

void add_scm_init_func (void (*f) ())
{
  if (!scm_init_funcs_)
    scm_init_funcs_ = new vector<Void_fptr>;

  scm_init_funcs_->push_back (f);
}

Which is called by the macro (called at top level)

#define ADD_SCM_INIT_FUNC(name, func)           \
  class name ## _scm_initter                    \
  {                                             \
  public:                                       \
    name ## _scm_initter ()                     \
    {                                           \
      add_scm_init_func (func);                 \
    }                                           \
  }                                             \
    _ ## name ## _scm_initter;


Where is the point in not using a vector for scm_init_funcs but a
pointer to such a vector, and just allocating the vector on the first
call?

SPOILER
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v

A pointer is a primitive data structure that is zero-initialized more or
less at load time before any constructors are getting called.  The order
in which constructors are called when several files are compiled is
undefined.  The constructor for vector initializes the vector to empty
which happens to be identical to what is initialized at load time, but
the constructor cannot distinguish between vectors in static variables
and on the stack where the initialization is mandatory.

Since construction order is arbitrary, a purportive *vector* (rather
than a pointer) scm_init_funcs_ would be getting filled by several calls
to add_scm_init_func (which works without complaint on the
zero-initialized memory of the vector) *before* the scm_init_funcs_'s
own constructor gets around to getting called and clears out everything
accumulated in scm_init_funcs_ so far, "initializing" it to empty.  Of
course, the calls accumulated so far are then missing.

C++ is not a programming language, it is a nightmare.  And would you
think that the pointer workaround in guile-init.cc was deemed worthy of
a single comment?  I consider it likely that this code already has had
hours of debugging invested in order to figure out the problem, and it
would have warranted _mentioning_.

At any rate, I'll come back with a streamlined version of 4360 first and  
then restart here.

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings