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