bug#25119: Acknowledgement (Hard freeze when switching to indirect buffer)

[Eli Zaretskii <eliz@gnu.org>]

> From: Ryan Johnson <scovich@gmail.com>
> Date: Mon, 5 Dec 2016 10:37:02 -0700
> 
> (gdb) xbacktrace
> "read-key-sequence-vector" (0x57f89050)
> 0x4872440 PVEC_COMPILED
> "funcall" (0x57f89190)
> "read-key" (0x57f89498)
> "read-char-choice" (0x57f89600)
> "ask-user-about-supersession-threat" (0x57f897b8)
> "put-text-property" (0x57f8bae8)
> "jit-lock-fontify-now" (0x57f8bc78)
> "jit-lock-function" (0x57f8be38)
> "redisplay_internal (C function)" (0xb856a8)

This looks like Emacs asking you whether to steal the lock from
another Emacs session that is editing the same file.

> The hang usually occurs when I switch to an indirect buffer I've not 
> used in a while (overnight, in this case), and on a shared machine where 
> people often run memory-intensive workloads. The backtrace above 
> suggests that the file has been modified outside emacs in the meantime, 
> which is probably true, since I frequently use patch queues.
> 
> I start to suspect that there's some sort of race here, where switching 
> to the buffer is slow (perhaps due to page faults) and a different 
> thread tries to process subsequent keystrokes, which triggers the "$FILE 
> changed on disk; really edit the buffer?" message while the mini-buffer 
> is still tied up with the "switching to..." message.

What other thread did you have in mind?  Emacs does all this in a
single thread.

> I will admit I never tried typing "y" or "n" in response to the
> hang... I'll be sure to try that next time.

Yes, a good idea.

Also, perhaps you could try a newer version of Emacs (25.1), maybe
this problem is already fixed there.

Thanks.