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: malloc: performance improvements and bugfixes


On Mon, 2016-01-25 at 16:50 -0800, Paul Eggert wrote:
> Thanks for doing all the work and bringing it to our attention. A couple 
> of comments on the process:
> 
> On 01/25/2016 04:24 PM, Joern Engel wrote:
> > I happen to prefer the kernel coding style over GNU coding style.
> 
> Nevertheless, let's keep the GNU coding style for glibc. In some places 
> the existing code doesn't conform to that style but that can be fixed as 
> we go.
> 
> > I believe there are some applications that
> > have deeper knowledge about malloc-internal data structures than they
> > should (*cough*emacs).  As a result it has become impossible to change
> > the internals of malloc without breaking said applications
> 
> This underestimates Emacs. :-)
> 
> Emacs "knows" so much about glibc malloc's internal data structures that 
> Emacs should do the right thing if glibc removes the hooks in question. 
> Of course we should test the resulting combination. However, the point 
> is that Emacs's usage of glibc malloc internals shouldn't ossify glibc 
> malloc.
> 
So why not fix emacs to stop doing this (purely evil behavior).

If they want to persist their internal state from session to session
there are better ways. For example: https://sphde.github.io/


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