Re: When should ralloc.c be used?

[Eli Zaretskii]

> Cc: address@hidden
> From: Paul Eggert <address@hidden>
> Date: Mon, 24 Oct 2016 09:21:50 -0700
> 
> On 10/24/2016 12:44 AM, Eli Zaretskii wrote:
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358... Then there's 
> > bug#24764 ...
> 
> These bugs seem to be fixed now (thanks to you!).

Some of them are fixed.  At least one more remains (I hope to fix it
soon).  What's more, we still don't know whether the changes in
regex.c by Noam are correct enough to solve the problems with
relocation of buffer text while we search the buffer, and we also
don't know yet whether the two bugs mentioned above are solved because
we didn't hear from their OPs.

Since these all are related to ralloc.c, the question is whether we
should get rid of using it on GNU/Linux, instead of chasing each of
these problems (which is anything but easy and might take time).

> As Andreas pointed out, the problems with ralloc.c are not as severe
> as initially feared, since they should be limited to pointers to
> buffer text and should not extend to pointers to Lisp strings.

Indeed, and that's a relief.

> As I understand it, although the ralloc.c approach worked for a long 
> time, it fell out of favor on common platforms and so hasn't been 
> debugged as thoroughly for the past several years. Unfortunately, recent 
> changes to glibc have caused ralloc.c to be used again on common GNU 
> platforms and this are shaking out longstanding bugs with the ralloc.c 
> approach. This means people using bleeding-edge glibc are suffering 
> problems similar to what people on now-unusual platforms must have had 
> for some time.

Yes, exactly.  And since most people at least here use Emacs on
GNU/Linux, the nasty problems due to ralloc.c are popping up much
faster and more frequently than they did when only *BSD and Windows
used ralloc.c.

> Surely we can fix these ralloc.c-related bugs as they come up. That 
> being said, they are a hassle for users and maintainers, and if dropping 
> ralloc.c works and doesn't cause significant performance degradation it 
> sounds like that would be a win.

Right, so I'd like your opinion and comments about the possible
solutions proposed so far:

  . Build with gmalloc but without ralloc.

  . Back-port the HYBRID_MALLOC changes from master.  Not sure if the
    patch is simple and safe enough, or whether the result is tested
    well enough to have that on emacs-25.

  . Build with gmalloc and use mmap for buffer text allocation.

Thanks.