Re: It's almost 2016 and when (single-threaded) Emacs hangs, you gotta be smashing your keyboard!

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 19 Nov 2015 21:55:06 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> > FWIW, it isn't unreliable or fragile for me.  It is rather rock-solid,
> > my sessions are usually open for many weeks on end, and almost never
> > crash or hang.
> 
> Exactly, "almost never", but hangs DO happen.

Not here.  I have crashes maybe once or twice a year, that's all.  No
hangs.

> >> It may freeze or it may not freeze, but if it does, all of the
> >> unsaved work is lost, not to mention the fact that all of the layout
> >> of windows and open buffers are lost as well.
> >
> > Neither of this is true.  When Emacs hits a fatal error, it
> > auto-saves, and if you activate the desktop-saving feature, it will
> > save a snapshot of your window and frame configuration fairly
> > frequently, so starting a new session recreates at least those buffers
> > which were visiting files or directories.
> 
> Could you please provide concrete settings for this?

Desktop saving is in the manual, see the node "Saving Emacs Sessions".

Auto-saving on fatal errors happens by default, but you should select
the signal you use to kill Emacs wisely: e.g., "kill -9" is usually a
bad idea.

> Also, maybe it does save on fatal error, but you have no chance of
> saving upon killing the Emacs process due to dead hang.

Signals that can be caught are treated the same as fatal errors.
Emacs catches them all, and auto-saves before committing suicide.

You can also bind commands to SIGUSR1 and SIGUSR2 events, you will
find documentation and example in the "Misc Events" node of the ELisp
manual.  Then you can "kill -USR1 emacs-PID", and have it auto-save,
or maybe call 'error' to get to top level.

> >> First of all, I just want to once again draw your attention to one
> >> of the urgent issues (to this date) of Emacs.
> >
> > Which urgent issue is that?
> 
> The one described above: dead handing.

AFAIR, you are the first who thinks this happens frequently enough to
be a serious issue.  Unless you are using development snapshots, where
all bets are off.  (I was talking about official releases.)  But
anyway, in every such case attaching the debugger to Emacs and
reporting a bug with the details about where it hangs, or at least
providing a recipe and any information regarding the hang you can come
up with, is the only efficient way to make the situation better.
Complaining here certainly won't cut it.

> >> And, secondly, I want to ask whether there exists a way to solve the
> >> problem described above without multi-threading?
> >
> > On Posix systems, Emacs does use a kind of multi-threading: it invokes
> > the 'ls' command to generate the directory listing.  You can configure
> > Emacs on Windows to do the same, if you can get your hands on a decent
> > port of GNU 'ls'.
> >
> 
> I'm using 'ls' on both Linux and Windows and this does not prevent the
> occasional hang on network directories.

But then it's 'ls' that's hanging, not Emacs, right?  Emacs just waits
for 'ls', and it should be relatively easy to interrupt the wait,
either by "C-g" or by sending a signal, see above.