Re: Malloc timeline.

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 17 Dec 2013, Ondrej Bilka wrote:

> The most ugrent step for 2.19 is announce which features will not be
> supported (malloc_set_state, malloc hooks...), for these we should
> prepare a copy of current allocator as separate library.

I don't think "as separate library" makes sense here.  I don't think glibc 
should be in the business of shipping multiple malloc libraries.  If a 
feature is to be supported, it should be supported in the default malloc 
in libc.  If not, it still needs to be supported for existing binaries 
forever, although compat symbols may prevent new binaries from using it.

> Could somebody review features and write which are needed and which are
> not?

If you want to remove a feature from malloc you should do the analysis of 
existing users (using the various tools out there for searching large 
amounts of free software source code).  There's also the option of marking 
interfaces with __attribute_deprecated__, putting a prominent note in the 
NEWS file about the proposal to desupport them for new binaries, and 
waiting for GNU/Linux distributions to do rebuilds to see what the impact 
of the change is (this may mean waiting several months for such feedback).

In addition, anyone wishing to remove features from malloc should work 
with users to find better alternatives for any problematic features.  
Thus, you should work directly with the Emacs development community to 
understand their requirements for which they use malloc_get_state / 
malloc_set_state, so as to develop a better alternative that Emacs can use 
in future that doesn't cause problems for changing malloc's internal 
datastructures.  malloc_get_state / malloc_set_state can't be turned into 
compat symbols until Emacs is no longer using them.

> A second urgent item to resolve is make malloc signal safe. This is
> prerequisite for improving performance, we could choose either that or
> decide that memory corruption from signal invocation is user problem.

I think it should be considered a user problem and signal safety should 
not be part of the malloc interface we provide.

-- 
Joseph S. Myers
joseph@codesourcery.com