
Removing support for Emacs unexec from Glibc - jordigh
https://lwn.net/SubscriberLink/673724/d9809e674cde21df/
======
nuxi7
For the curious, the need to change the malloc behavior is not hypothetical:

[https://sourceware.org/bugzilla/show_bug.cgi?id=6527](https://sourceware.org/bugzilla/show_bug.cgi?id=6527)

Basically for many years now glibc has been knowingly doing the wrong thing
just to keep malloc_set_state/malloc_get_state working. Which as far as anyone
knows, is used only by emacs. Keeping this interface alive for the sole
benefit of an emacs optimization when it is blocking the fixes for fairly
serious bugs is a pretty big bar to meet for justification.

In the end this is largely a non-issue as an Emacs developer noted that their
configure script probes for the special glibc malloc API and if it doesn't
exist then emacs will use its own malloc implementation. The conclusion is
that once the glibc devs get their changes up, everyone can meet up again to
make sure existing emacs binaries still run and that the API detection in the
emacs configure script works right.

So props to Paul Eggert for being the only sane man in the room and pointing
out that the drama was all for nothing.

------
_yosefk
Actually, having a generic way of saving the program state into an executable
that then runs from that point could be really useful, and some Unix versions
had it (and Perl used a Unix utility called undump to implement a "Perl
compiler" where it dumped core that could be "undumped" into a running program
later; that's the same idea as "unexecing" program state into an executable.)

~~~
johntb86
[http://criu.org/Main_Page](http://criu.org/Main_Page)

~~~
Freaky
Also: [https://www.dragonflybsd.org/cgi/web-
man?command=sys_checkpo...](https://www.dragonflybsd.org/cgi/web-
man?command=sys_checkpoint&section=2)

------
tenfingers
Approaches similar to unexec() are quite common in lisp-like environments, so
emacs doesn't come as a "surprise" here.

There's no reason emacs needs to use the glibc's malloc implementation though,
especially given emacs has it's own built-in (and probably neglected) malloc
for other platforms.

~~~
mcguire
Yep. Emacs builds and runs (and presumably unexecs) on many non-glibc
platforms. This is more likely an optimization for it on glibc.

" _According to Paul Eggert, making unexec more portable has been on the to-do
list for a while, "and this will light more of a fire under it". Concerns that
Emacs might not build using a new Glibc API (which has not even been written
yet) that came up earlier in the thread are not a problem, he said. "Emacs
should still build and run even if the glibc API is changed, as Emacs
./configure probes for the glibc malloc-related API and falls back on its own
malloc implementation otherwise."_"

And there's the dreaded autoconf doing it's job.

~~~
justincormack
Well no it does not unexec on other platforms. And the figures in the article
suggest it is annoyingly slow to start on other platforms. This is all about
making the Gnu editor work well on the Gnu OS. It builds and runs elsewhere
but startup is slow.

------
mwcampbell
I think it's wrong for any application to be this intimate with its host
platform. In my opinion, Emacs should treat libc as a black box on GNU/Linux,
just as it presumably does on Windows, OS X, and other proprietary platforms.
But I admit that my opinion is shaped by being a user and developer of
proprietary software, where binary compatibility is important. So I'm not
surprised that RMS apparently disagrees.

~~~
ma2rten
I think it's common for applications that are developed by same organization
as the OS. Windows also has private APIs for some MSFT applications.

~~~
afarrell
> I first heard about this from one of the developers of the hit game SimCity,
> who told me that there was a critical bug in his application: it used memory
> right after freeing it, a major no-no that happened to work OK on DOS but
> would not work under Windows where memory that is freed is likely to be
> snatched up by another running application right away. The testers on the
> Windows team were going through various popular applications, testing them
> to make sure they worked OK, but SimCity kept crashing. They reported this
> to the Windows developers, who disassembled SimCity, stepped through it in a
> debugger, found the bug, and added special code that checked if SimCity was
> running, and if it did, ran the memory allocator in a special mode in which
> you could still use memory after freeing it.

[http://www.joelonsoftware.com/articles/APIWar.html](http://www.joelonsoftware.com/articles/APIWar.html)

------
quotemstr
IMHO, the XEmacs approach of using a portable dumper is the better option. I
prefer that one not only because it frees us from having to worry about the
details of executable formats, but because the same machinery that lets us
find and relocate all the intra-lisp-heap pointers would also let us write a
compacting GC, which is important for long-running programs like Emacs.

------
weinzierl
> [..] fixing Emacs, which is seen as the only user of the interfaces:

If I remember correctly TeX uses the same trick. I don't know if it depends on
unexec() though.

~~~
coliveira
From what I remember TeX dumps the processed macros into a binary file. Later,
TeX loads those preprocessed formats quickly, without the need to parse again
something as big as LaTeX.

------
jbssm
I wonder if there is any project starting to re-write Emacs according to
modern practices like we now have NeoVIM for VIM.

I really like editing in VIM but I moved to Emacs using Spacemacs to try and
get the best of both worlds (org mode for scientific research seems a really
cool approach).

Still I see Emacs as being quite more bug prone than VIM and VIM than NeoVIm.

Perhaps this is what's needed for someone to start a complete refactor of
Emacs and bring it (I mean the code not the editor) to the modern age.

~~~
dmm
I don't really see that as being the case. Emacs development is very active,
even at the low levels. The Guile scheme implementation now has an elisp
implementation and there's a good chance that emacs will be moved to it
eventually.

If you encounter bugs you should submit bug reports.

~~~
wtbob
> The Guile scheme implementation now has an elisp implementation and there's
> a good chance that emacs will be moved to it eventually.

FWIW, I think that's entirely the wrong direction to go. Emacs should be
ported to Common Lisp, with an elisp compatibility layer.

Scheme's a neat didactic tool, but anyone who wants to produce production-
level software in Lisp should write it in Common Lisp. Heck, even Schemers
recognise that, which is why the RnRS controversy exists.

~~~
pmoriarty
My own view is that Scheme is exactly the right way to go and CL would have
been the wrong way to go.

Modern Schemes are fully as production-ready as CL. The view of Scheme as
merely an educational tool is outdated, and usually based on limited
experience with ancient, bare-bones Scheme implementations such as MIT Scheme.

Modern Schemes like Chicken have fairly extensive collections of practical
libraries and features that barebones Scheme implementations lack. To add to
that, Scheme is far more elegant than CL, and doesn't contain all of the
ancient crud of CL, so is far more pleasant and easy to program in.

I'm not thrilled that Guile (rather than Chicken) is the Scheme of choice for
Emacs, but it's a far better choice than CL.

That said, even CL would have been an enormous improvement over elisp. So the
sooner the migration from elisp starts (whether to Scheme or CL), the better.

~~~
wtbob
> Modern Schemes are fully as production-ready as CL.

Modern Scheme still doesn't have hash tables (c.f. R7RS[1]; of course Lisp has
them). That, right there, prevents it from being a production-ready language.
I could omit the rest of this post and I'd be right.

Scheme does have continuable exceptions, but it's still a far cry from Lisp's
conditions and restarts.

Scheme's type system is extraordinarily lightweight. There's no way for the
user to define new types, nor even a lightweight way to query for an object's
type (unless I've missed something, one must use the various type predicates
one-by-one).

Relatedly, there's no way to declare variable or function types; no way to
pass that information on to an optimising compiler. There are no compiler
macros. Indeed, compilation in general is woefully underspecified.

There's no object-orientation: no classes, no generic functions, none of that.
One has to roll one's own if one wishes to.

Although it does have cond-expand, unlike Lisp Scheme doesn't specify _READ-
SUPRESS_ which works in conjunction with #+ and #- to skip variant syntax
supported by other implementations.

This raises the issue of the reader in general. Scheme's reader is not
extensible; it lacks reader macros. It provides no access to the current
readtable, or any way to manipulate it.

Scheme doesn't even have a general (i.e., unhygienic) macro facility! Its
hygienic macros are sufficient for many use cases, but not all — e.g.
anaphoric macros.

Its iteration construct (yes, singular!) is severely limited. There's no
general facility like LOOP.

It lacks settable places (this is the capability in Lisp of writing `(setf
(getf 'foo bar) 'baz)`).

Scheme does finally have dynamic variables, although they are more unwieldy to
use than Lisp's specials.

I do like its well-specified numeric tower.

> Modern Schemes like Chicken have fairly extensive collections of practical
> libraries and features that barebones Scheme implementations lack.

But they require that for even very basic functionality (like hashtables!).
One of Common Lisp's downfalls is having to use implementation-specific
functionality; Scheme is worse.

A related problem with Lisp is that Gray streams aren't part of the standard.
But Scheme's ports are even less-specified than Lisp's streams.

> To add to that, Scheme is far more elegant than CL, and doesn't contain all
> of the ancient crud of CL, so is far more pleasant and easy to program in.

You know what I find pleasant? A language which anticipates my needs and my
problems, and has already solved them. Time and time again I find that Common
Lisp has done exactly that.

I'll certainly admit that there are parts of Lisp I'd change (the default
upcasing is hideous; some of the function names are ugly; the varying argument
order between similar functions is beyond lame). But I'd never want to use a
language which treats NIL as true!

Scheme's not really a toy: it's clay which can be used by thinkers as well as
students to play with problems. But it's not suitable for writing portable,
high-performance, industrial-strength, real-world problems. Common Lisp is.

[1]
[http://trac.sacrideo.us/wg/wiki/R7RSHomePage](http://trac.sacrideo.us/wg/wiki/R7RSHomePage)

------
fidget
> LWN subscriber-only content

kinda shitty

~~~
lultimouomo
If you try scrolling down, you'll note you can actually read the article. LWN
lets subscribers share (temporary) paywalled articles with anyone they like,
even on public forums like HN. They are nice like that.

~~~
fidget
Oh, I'm aware I can read it. I'm just not convinced about sharing it on such a
broad public forum.

~~~
lultimouomo
Sorry, I misunderstood what you meant.

Links to LWN subscriber content appear on HN from time to time - not too
often, and I would guess they do more good than harm to them.

~~~
markrages
Often such links are posted by LWN staff, so I believe they favor the
practice.

------
chris_wot
So much for rms standing up to principle. When the chips are down, he resorts
to a private mailing list to discuss and influence matters that impact
multiple users. I though he was into transparency?

------
ma2rten
I found it interesting that RMS wanted to discuss the issue in private given
his position as a almost religious defender of free software. Isn't a part of
free software that it is developed in the open?

~~~
jordigh
rms doesn't think "free software" has anything to do with a responsibility for
collaboration or openness. Those are slogans of the open source movement. He
sees software as an ethical exchange between two parties. rms doesn't have a
problem with privacy, secrecy, or refusal to collaborate. As long as Bob has
the freedom to do whatever he wants with the software the Alice gave him
(except, perhaps, restrict the freedom of others), rms doesn't think that
Alice has any further moral obligations.

------
camgunz
Summary: emacs devs want glibc to maintain backwards compat in their heap
layout so building emacs is 5 seconds faster.

~~~
roel_v
No, _starting_ emacs is 5 seconds faster - at least that's what I got from it.

~~~
ams6110
Agree -- but doesn't strike me as a big deal. For me, emacs is something I
start and will often have running for months. 5 second startup time is
irrelevant. That's no slower than starting Word or Excel, either. Even
browsers take a couple of seconds to start from cold.

~~~
Scarblac
Not everybody does, and not everybody who does that does it on all systems.

A 5 second startup time for a text editor is extremely annoying when all you
want to do is, say, type some small commit message.

~~~
xxpor
Agreed. Even as a regular emacs user, if I just want to quickly edit a config
file on a remote box I just open nano or vim, because they open nearly
instantly.

~~~
ams6110
For local quick edits of things like commit messages, you can run emacs as a
daemon and use emacsclient as your editor command.

For remote files there's tramp.

But, I do agree that any sysadmin should know enough basic vi[m] to get
around, because vi is almost always available on any unix system. Emacs (or
nano) might not be installed.

