GNU bug report logs - #25247
26.0.50; Concurrency crashes

Previous Next

Full log

Message #92 received at 25247 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#25247: 26.0.50; Concurrency crashes with XLib
Date: Sat, 31 Dec 2016 20:29:48 +0200

> From: Elias Mårtenson <lokedhs <at> gmail.com>
> Date: Sun, 1 Jan 2017 02:16:41 +0800
> Cc: Tino Calancha <tino.calancha <at> gmail.com>, raeburn <at> raeburn.org, 25247 <at> debbugs.gnu.org
> 
>  "Ready to run" means here a thread that is stuck in
>  acquire_global_lock. One of those threads will succeed in acquiring
>  the lock when the thread which was previously running releases the
>  lock.
> 
> In this case, the thread died, and all other threads are idle. Wouldn't this trigger a redisplay?

When a thread dies, the global local is released, so some other thread
that waits for the lock can run.  But I don't think that should
trigger redisplay, because it means Emacs isn't idle.

I don't understand what you mean by "all other threads are idle".  I
don't think any of them are, but I'm not sure we have the same idea of
"idle" in this context.  For me, "idle" means a thread that waited for
input and didn't get any until its wait timeout expired.  Only after
that we say that Emacs is "idling".

>  Those which are still waiting for their sleep period to expire will
>  not run, because they are inside the pselect call. Only the threads
>  whose sleep period already expired are "ready to run", because they
>  call acquire_global_lock right after the pselect call returns.
> 
> But the way I interpreted what you were saying was that if there are no threads that are "ready to run" (as in
> this case), redisplay would be called.

Yes, but only after the main thread ends its waiting timeout.  That is
why having timers produces more frequent redisplay.

> If that was indeed what you were saying, then that doesn't match observed behaviour. If I misunderstood what
> you were saying, then things make sense.
> 
> I'm willing to bet that the latter is true.

I'm not sure, because I don't understand what exactly doesn't match
the observations.

>  It's perfectly normal for Emacs not to redisplay when some Lisp is
>  running. That is what happens here, except that "some Lisp" in this
>  case can come from another thread.
> 
> Fair enough. I guess the introduction of threads will make the redisplay function more important than it has
> been in the past.

Only if the non-main threads must produce some visible effect.  That's
not a given; they could instead do some background job that doesn't
directly affect the displayed text.

Previous Next

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