Subject: Re: bug#25247: 26.0.50; Concurrency crashes with XLib

From: Eli Zaretskii <[email-masked]>
Date: Fri, 30 Dec 2016 20:54:25 +0200

> From: Elias Mårtenson <[email-masked]>
> Date: Fri, 30 Dec 2016 19:21:08 +0800
> Cc: Tino Calancha <[email-masked]>, [email-masked], [email-masked]
> 
>  > Here, I'd expect to see the "z" buffer being updated at the corresponding
>  > times. I.e. the message "Foo:4" should be displayed after 4 seconds. This
>  > is not what I see. Instead the messages appear in batches (i.e. several
>  > rows appearing at the same time).
> 
>  And what do the messages that appear together say in the %d part? Do
>  they all show the same value?
> 
> No. They show wildly different values. For example, during one test, after roughly 8 seconds, I got 7 or so
> messages with number ranging from 2 to 8.

I think the results are unexpected only because you think of the
threads as running in parallel.  But they don't; only one thread runs
at any given time, the rest are stuck, either in 'pselect', waiting
for some input or time-out, or waiting for the global lock to become
available.  And sleep-for yields to other threads (i.e. makes the
global lock available).

> One interesting fact is that if I replace ‘sleep-for’ with ‘sit-for’, then the updates come at exactly the expected
> time. In other words, the unpredictable behaviour where keypresses would randomly make the ‘sit-for’ expire
> doesn't happen anymore.

What keypresses did you have in mind?