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

[Ryan Johnson <scovich@gmail.com>]

On 12/5/2016 11:44 AM, Eli Zaretskii wrote:
>> (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 message from the lisp backtrace was:
> AlphaTree.cpp changed on disk; really edit the buffer? (y, n, r or C-h)

I'm pretty sure the lock-stealing message is rather different from that, 
mentioning the PID of the other emacs... but I don't remember off the 
top of my head because I very rarely point two emacsen at the same file.

>> 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.
Just a wild speculation, based on the fact that it was apparently stuck 
waiting for input while still trying to redraw the screen. Even in a 
single thread, signals might allow a self-deadlock of some kind. Or it 
could be something else entirely.

> Also, perhaps you could try a newer version of Emacs (25.1), maybe
> this problem is already fixed there.
Will build it and switch over; I don't think it's available for Ubuntu 
16 LTS.

Ryan