Re: Dumper problems and a possible solutions

[Rich Felker <dalias@libc.org>]

On Wed, Jun 25, 2014 at 10:30:22PM +0400, Dmitry Antipov wrote:
> On 06/25/2014 10:08 PM, Rich Felker wrote:
> 
> >Are there such objects that need to be preserved across dumping?
> 
> I don't know, and the worst thing is that we can't control over this.

Sure you can. If the lisp code doesn't reference such objects then
their existence of nonexistence is irrelevant to the new emacs
invocation after dumping.

> With my debug build, 'ldd src/temacs  | wc -l' shows 112 external
> libraries. What if just one of these libraries uses malloc() to allocate
> an internal object in __attribute__((constructor)) function?

If these libraries are shared libraries, all of that state will be
lost during dumping and reinitialized when the library is loaded again
at runtime.

As long as we're using the existing dumper system, where the whole
data segment gets written out to a new executable file, I agree
there's such a problem for static linking. But if emacs switched to
the new system I proposed, where ONLY the lisp state were dumped to a
static array, then none of these libraries' state could be saved at
all, and thus there would be no danger.

Rich