bug#25247: 26.0.50; Concurrency crashes with XLib

[Eli Zaretskii]

> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Sun, 1 Jan 2017 02:16:41 +0800
> Cc: Tino Calancha <tino.calancha@gmail.com>, raeburn@raeburn.org, 
> 25247@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.