This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

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 justthat 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 platformsthat have multithreaded Emacs.

References:
- Fwd: glibc and unexec
  - From: Mark Brown
- Re: Fwd: glibc and unexec
  - From: Joseph Myers
- Re: Fwd: glibc and unexec
  - From: Paul Eggert
- Re: Fwd: glibc and unexec
  - From: Florian Weimer

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]