[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25247: 26.0.50; Concurrency crashes with XLib

From: Elias Mårtenson
Subject: bug#25247: 26.0.50; Concurrency crashes with XLib
Date: Sat, 31 Dec 2016 23:34:33 +0800

On 31 December 2016 at 19:05, Eli Zaretskii <address@hidden> wrote:
> From: Elias Mårtenson <address@hidden>
> Date: Fri, 30 Dec 2016 19:21:08 +0800
> Cc: Tino Calancha <address@hidden>, address@hidden, address@hidden
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]