bug#25247: 26.0.50; Concurrency crashes with XLib

[Eli Zaretskii]

> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Sat, 31 Dec 2016 23:34:33 +0800
> Cc: Tino Calancha <tino.calancha@gmail.com>, raeburn@raeburn.org, 
> 25247@debbugs.gnu.org
> 
> I always turn off blink-cursor, but just to ensure that I was correct, I 
> tried to reproduce with -Q and that was
> very revealing.
> 
> With -Q and only turning off blink-cursor-mode, I get no updates until I hit 
> a key. With blink-cursor-mode on, it
> updates during the blinking phase just as you suggested it would.
> 
>  When blink-cursor-mode is ON, it supplies 2 events each second, and
>  that allows the threads that finished waiting to acquire the global
>  lock and insert the string. Otherwise, the threads wait for the
>  global lock and do the insertions at the end.
> 
> I can only conclude that one of my millions of customisations triggers a 
> refresh at some interval that is rougly
> 4-5 seconds.

Look at timer-idle-list for possible illumination.  Failing that, look
at timer-list.

When timers are active, wait_reading_process_output (which is where
implicit thread switches are triggered) reduces the timeout values it
uses when it calls thread_select/pselect.  It does so in order not to
miss the time when the next timer is set to expire.  That makes the
Emacs main loop crank at higher frequency, and each cycle brings
another chance for another thread to start running, because
thread_select starts by releasing the global lock.

So what a frequent timer does is it allows threads that finished
waiting in sit-for to run the rest of their code, which is insert the
string into the buffer.

> I also discovered that the event is actually triggered (i.e. the call to 
> sleep-for actually finishes on-time but it's
> just the buffer content that are not updated). That makes things a lot more 
> clear for me.

Yes, because the thread which finished its sleep time goes on to
reacquire the global lock, and waits for that to be come available.

> Now, this begs the question: Is this the appropriate behaviour? It would be 
> very nice if buffer updates made by
> threads were immediately updated on the screen. If that is not possible for 
> some reason, I think there should
> be some way for Elisp code to force the repaint of a buffer.

I think the update on screen is indeed immediate, it's just that
insertion doesn't happen immediately after the sleep period ended.