bug#25247: 26.0.50; Concurrency crashes with XLib

[Elias Mårtenson]

On 31 December 2016 at 19:05, Eli Zaretskii <eliz@gnu.org> wrote:

> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Fri, 30 Dec 2016 19:21:08 +0800
> Cc: Tino Calancha <tino.calancha@gmail.com>, raeburn@raeburn.org, 25247@debbugs.gnu.org
>
> One interesting fact is that if I replace ‘sleep-for’ with ‘sit-for’, then the updates come at exactly the expected
> time.

But only as long as blink-cursor-mode is turned on, right?  If you
turn it off before running the experiment, sit-for behaves the same as
sleep-for, right?

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.

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.

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.

Regards,

Elias