This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Malloc timeline.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Allan McRae <allan at archlinux dot org>, <libc-alpha at sourceware dot org>
- Date: Tue, 17 Dec 2013 14:17:52 +0000
- Subject: Re: Malloc timeline.
- Authentication-results: sourceware.org; auth=none
- References: <20131217120834 dot GA29241 at domone dot podge>
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