Re: When should ralloc.c be used? (WAS: bug#24358)

[Eli Zaretskii]

> From: Richard Stallman <address@hidden>
> CC: address@hidden, address@hidden,
>       address@hidden
> Date: Mon, 24 Oct 2016 22:35:53 -0400
> 
>   > > Should we talk with them about putting in those hooks or other
>   > > suitable hooks?  Then we could go back to the libc malloc.
> 
>   > I think we tried, and more or less failed.  (That was in the context
>   > of unexec, but the arguments are more or less similar.)
> 
> How did it fail?

My take is that the glibc developers don't really want to hear about
keeping those hooks.

> Did they give it a strong try?

I don't know what that means in practice.  What would make the try
"strong"?

You can see the discussion starting here:

  http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg00956.html

You took some part in the discussion, at least its public part (I
understand there was also an off-list part).  I think once you said
here:

  http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01633.html

that you favored replacing unexec by a more portable scheme, there was
no longer any reasons to make our argument stronger.

Since then Paul implemented a workaround on the master branch, which
uses gmalloc during dumping, and switches to the native malloc in the
dumped executable.

At the time, we didn't realize, I think, that removing the glibc hooks
will cause GNU/Linux systems to start using ralloc.c, which is the
trigger for the present discussion.  The discovery of this issue means
that the hope expressed in the Jan 2016 discussions that Emacs
versions before 25 will continue to be usable on GNU/Linux systems
with a newer glibc -- that hope was too optimistic.  Based on what
we've learned the hard way during the last couple of weeks, I'd say
that all the Emacs versions before 25.2 (including 25.1) will be
unstable on such GNU systems to the degree of making them almost
unusable.  E.g., one bug report related to this claims crashes inside
GC once every 10-15 minutes, something that is IMO unbearably
frequent, especially given that segfaults during GC almost always
cause loss of work (because auto-saving almost always fails).