This is the mail archive of the
mailing list for the glibc project.
Re: Fwd: glibc and unexec
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Florian Weimer <fweimer at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Mark Brown <ms_brown at sbcglobal dot net>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 19 Jan 2016 00:11:16 -0800
- Subject: Re: Fwd: glibc and unexec
- Authentication-results: sourceware.org; auth=none
- References: <E1aLIs3-00021d-VR at fencepost dot gnu dot org> <569D7328 dot 5030502 at sbcglobal dot net> <alpine dot DEB dot 2 dot 10 dot 1601182327430 dot 18513 at digraph dot polyomino dot org dot uk> <569DA266 dot 4010201 at cs dot ucla dot edu> <569DE6A6 dot 6070206 at redhat dot com>
Florian Weimer wrote:
In my test, Emacs simply interposed
its own bundled malloc implementation, which is quite the opposite of
âgetting out of the malloc businessâ.
Yes, this approach is merely a stopgap and we need something better; it's just
that whatever we come up with probably won't be ready in time for Emacs 25.
a multi-threaded Emacs will
likely exercise gmalloc.c in new ways not originally expected.
That's one worry, yes. That being said, gmalloc does work on non-glibc platforms
that have multithreaded Emacs.