unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Elias Mårtenson" <lokedhs@gmail.com>
Cc: raeburn@raeburn.org, tino.calancha@gmail.com, 25247@debbugs.gnu.org
Subject: bug#25247: 26.0.50; Concurrency crashes with XLib
Date: Sat, 31 Dec 2016 20:06:21 +0200	[thread overview]
Message-ID: <83h95kgehu.fsf@gnu.org> (raw)
In-Reply-To: <CADtN0WJ+eE8AufDVZQWzAqOaF8uVvWBnTvdek-tzkSyxXmh1dQ@mail.gmail.com> (message from Elias Mårtenson on Sun, 1 Jan 2017 01:28:10 +0800)

> 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.

> They're all sitting in 'sleep-for' already.

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.

>  > Interestingly enough, the minibuffer message does get updated.
> 
>  Displaying minibuffer messages uses a separate entry to redisplay, and
>  that entry only displays the echo area, unless it needs to resize the
>  mini-window.
> 
> I see. I did notice that calling 'redisplay' after the 'insert' makes everything work exactly the way I'd expect it to.
> 
> 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.





  reply	other threads:[~2016-12-31 18:06 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-22 10:20 bug#25247: 26.0.50; Concurrency crashes Tino Calancha
2016-12-22 17:28 ` Eli Zaretskii
2016-12-23  3:34   ` Tino Calancha
2016-12-23  8:34     ` Eli Zaretskii
2016-12-23 11:32       ` Tino Calancha
2016-12-23 14:14         ` Eli Zaretskii
2016-12-29 11:37           ` bug#25247: 26.0.50; Concurrency crashes with XLib Tino Calancha
2016-12-29 17:44             ` Eli Zaretskii
2016-12-30  3:13               ` Tino Calancha
2016-12-30  7:19             ` Ken Raeburn
2016-12-30  8:37               ` Eli Zaretskii
2016-12-30  9:41                 ` Eli Zaretskii
2016-12-30 10:30                   ` Elias Mårtenson
2016-12-30 11:05                     ` Eli Zaretskii
2016-12-30 11:21                       ` Elias Mårtenson
2016-12-30 18:54                         ` Eli Zaretskii
2016-12-30 20:40                           ` Eli Zaretskii
2016-12-31 11:05                         ` Eli Zaretskii
2016-12-31 15:34                           ` Elias Mårtenson
2016-12-31 15:51                             ` Eli Zaretskii
2016-12-31 16:24                               ` Elias Mårtenson
2016-12-31 17:18                                 ` Eli Zaretskii
2016-12-31 17:28                                   ` Elias Mårtenson
2016-12-31 18:06                                     ` Eli Zaretskii [this message]
2016-12-31 18:16                                       ` Elias Mårtenson
2016-12-31 18:29                                         ` Eli Zaretskii
2016-12-31 18:38                                           ` Eli Zaretskii
2016-12-30 13:45                   ` Tino Calancha
2016-12-30 16:57                     ` Eli Zaretskii
2017-01-06  0:03                       ` npostavs
2017-01-06  7:48                         ` Eli Zaretskii
2016-12-23  9:34   ` bug#25247: 26.0.50; Concurrency crashes Ken Raeburn
2016-12-23 10:04     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83h95kgehu.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=25247@debbugs.gnu.org \
    --cc=lokedhs@gmail.com \
    --cc=raeburn@raeburn.org \
    --cc=tino.calancha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).