Re: Reinitializer failing to run

Will Noble <[email protected]> Tue, 30 Apr 2013 10:08:02 -0700
Newsgroups gmane.lisp.scheme.scheme48
Message-ID <[email protected]>
On Tue, Apr 30, 2013 at 03:40:05PM +0200, Michael Sperber wrote:
> Hmmm.  It seems the problem is not so much the mechanism but that there
> is no path from `date' to the reinitializer for the signal handlers.
> Otherwise, it'd be likely that reinitializers would pollute images
> dumped with a resumer procedure.  Having said that, I'll have to think a
> bit more about how to create such a path.

What I meant was that by changing the mechanism of reinitializers, we could
forget about the transitive closure of the resumer procedure and simply
include every reinitializer. I can think of a couple of reasons for doing
things this way.

For one thing, we already reload dynamically loaded libraries when resuming
from a resumer procedure-type dumped image. In this case, posix.so has
already polluted the image without the benefit of having signals work,
because of the missing reinitializer.

Second, the signal handler reinitializer doesn't do anything heavy. It only
arranges for the system to pick up on signals. To receive those signals the
user has to use the provided functions. Otherwise they would observe not
observe any effects.

Of course, it would be great if we don't get any unneeded reinitializers (or
code to reload unneeded share objects) in images. I think for that we would
need to have procedures refer to their containing packages, and have
packages refer to package-specific reinitializers.

Best,
Will