GNU bug report logs - #25247
26.0.50; Concurrency crashes

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elias Mårtenson <lokedhs <at> gmail.com>
Cc: raeburn <at> raeburn.org, 25247 <at> debbugs.gnu.org, tino.calancha <at> gmail.com
Subject: bug#25247: 26.0.50; Concurrency crashes with XLib
Date: Fri, 30 Dec 2016 20:54:25 +0200

> From: Elias Mårtenson <lokedhs <at> gmail.com>
> Date: Fri, 30 Dec 2016 19:21:08 +0800
> Cc: Tino Calancha <tino.calancha <at> gmail.com>, raeburn <at> raeburn.org, 25247 <at> debbugs.gnu.org
> 
>  > 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.