From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#25247: 26.0.50; Concurrency crashes with XLib Date: Sat, 31 Dec 2016 20:06:21 +0200 Message-ID: <83h95kgehu.fsf@gnu.org> References: <87bmw4w9i2.fsf@gmail.com> <83a8bn27qn.fsf@gnu.org> <87h95vmi7b.fsf@gmail.com> <83wperyrgj.fsf@gnu.org> <878tr651a9.fsf@gmail.com> <83mvfmzq9n.fsf@gnu.org> <87shp7j790.fsf_-_@gmail.com> <06A3A860-6057-4932-A654-F7663B432DEB@raeburn.org> <83bmvtu81z.fsf@gnu.org> <838tqxu535.fsf@gnu.org> <834m1lu16d.fsf@gnu.org> <83tw9kgxyy.fsf@gnu.org> <83mvfcgkqu.fsf@gnu.org> <83k2agggp9.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1483207645 11470 195.159.176.226 (31 Dec 2016 18:07:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Dec 2016 18:07:25 +0000 (UTC) Cc: raeburn@raeburn.org, tino.calancha@gmail.com, 25247@debbugs.gnu.org To: Elias =?UTF-8?Q?M=C3=A5rtenson?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 31 19:07:17 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNO3h-0000Y4-IV for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 19:07:09 +0100 Original-Received: from localhost ([::1]:45059 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNO3j-00030t-7G for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 13:07:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNO3d-00030d-KO for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:07:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNO3a-0006XT-ES for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:07:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46287) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cNO3a-0006XM-Ag for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:07:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cNO3a-0001Vi-1P for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:07:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 Dec 2016 18:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25247 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25247-submit@debbugs.gnu.org id=B25247.14832076085786 (code B ref 25247); Sat, 31 Dec 2016 18:07:01 +0000 Original-Received: (at 25247) by debbugs.gnu.org; 31 Dec 2016 18:06:48 +0000 Original-Received: from localhost ([127.0.0.1]:33453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNO3L-0001VG-V0 for submit@debbugs.gnu.org; Sat, 31 Dec 2016 13:06:48 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:37322) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNO3K-0001V4-9R for 25247@debbugs.gnu.org; Sat, 31 Dec 2016 13:06:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNO3B-0006Qi-Nz for 25247@debbugs.gnu.org; Sat, 31 Dec 2016 13:06:40 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48734) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNO3B-0006Qd-Ku; Sat, 31 Dec 2016 13:06:37 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1345 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cNO38-0004ZH-Lj; Sat, 31 Dec 2016 13:06:37 -0500 In-reply-to: (message from Elias =?UTF-8?Q?M=C3=A5rtenson?= on Sun, 1 Jan 2017 01:28:10 +0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:127638 Archived-At: > From: Elias Mårtenson > Date: Sun, 1 Jan 2017 01:28:10 +0800 > Cc: Tino Calancha , 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.