bug#25247: 26.0.50; Concurrency crashes with XLib

["Elias Mårtenson" <lokedhs@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]

On 1 January 2017 at 02:06, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Elias Mårtenson <lokedhs@gmail.com>
> > Date: Sun, 1 Jan 2017 01:28:10 +0800
> > Cc: Tino Calancha <tino.calancha@gmail.com>, raeburn@raeburn.org,
> 25247@debbugs.gnu.org
> >
> >  The display on the screen will only change if Emacs enters redisplay.
> >  If you see the file's contents change, but the display on the screen
> >  doesn't reflect that, it means Emacs does not get a chance to perform
> >  redisplay, because it doesn't become idle in any of the threads that
> >  are active. Which could be the case, since every time a running
> >  thread is about to become idle, there's another thread ready to run.
> >
> > I'm not sure exactly what you refer to when you say "ready to run".
> There are of course more threads, but
> > none of them should be "ready to run".
>
> "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?

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.

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 guess doing that is perfectly acceptable and understandable once one
> has had the benefit of someone
> > explaining it to him, like in this case. That said, it would be nice if
> I didn' thave to.
>
> 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.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 3542 bytes --]