[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: Eli Zaretskii
Subject: bug#25247: 26.0.50; Concurrency crashes with XLib
Date: Fri, 30 Dec 2016 20:54:25 +0200

> From: Elias Mårtenson <address@hidden>
> Date: Fri, 30 Dec 2016 19:21:08 +0800
> Cc: Tino Calancha <address@hidden>, address@hidden, address@hidden
>  > 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?

reply via email to

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