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:29:48 +0200 Message-ID: <83eg0ogder.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> <83h95kgehu.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 1483209085 24922 195.159.176.226 (31 Dec 2016 18:31:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Dec 2016 18:31: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:31:21 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 1cNOQs-0004ID-4K for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 19:31:06 +0100 Original-Received: from localhost ([::1]:45099 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNOQw-0006LT-U0 for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 13:31:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNOQr-0006KS-1S for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:31:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNOQn-0007wu-Vs for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:31:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46301) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cNOQn-0007wa-Sj for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:31:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cNOQn-00026B-Ob for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:31:01 -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:31: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.14832090037942 (code B ref 25247); Sat, 31 Dec 2016 18:31:01 +0000 Original-Received: (at 25247) by debbugs.gnu.org; 31 Dec 2016 18:30:03 +0000 Original-Received: from localhost ([127.0.0.1]:33467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNOPr-000242-4X for submit@debbugs.gnu.org; Sat, 31 Dec 2016 13:30:03 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNOPp-000233-B6 for 25247@debbugs.gnu.org; Sat, 31 Dec 2016 13:30:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNOPg-0007TP-Rz for 25247@debbugs.gnu.org; Sat, 31 Dec 2016 13:29:56 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNOPg-0007TL-Og; Sat, 31 Dec 2016 13:29:52 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1379 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cNOPf-0001qB-7d; Sat, 31 Dec 2016 13:29:52 -0500 In-reply-to: (message from Elias =?UTF-8?Q?M=C3=A5rtenson?= on Sun, 1 Jan 2017 02:16:41 +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:127641 Archived-At: > From: Elias Mårtenson > Date: Sun, 1 Jan 2017 02:16:41 +0800 > Cc: Tino Calancha , 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.