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 19:18:42 +0200 Message-ID: <83k2agggp9.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> 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 1483204817 20239 195.159.176.226 (31 Dec 2016 17:20:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Dec 2016 17:20:17 +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 18:20:11 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 1cNNKE-0004Og-5u for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 18:20:10 +0100 Original-Received: from localhost ([::1]:44967 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNNKJ-0004PO-82 for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 12:20:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNNKA-0004Ob-2v for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 12:20:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNNK5-0004ZH-TG for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 12:20:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46262) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cNNK5-0004ZC-QL for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 12:20:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cNNK5-0000PE-Kv for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 12:20: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 17:20: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.14832047491492 (code B ref 25247); Sat, 31 Dec 2016 17:20:01 +0000 Original-Received: (at 25247) by debbugs.gnu.org; 31 Dec 2016 17:19:09 +0000 Original-Received: from localhost ([127.0.0.1]:33428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNNJE-0000Nz-Nq for submit@debbugs.gnu.org; Sat, 31 Dec 2016 12:19:08 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57471) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNNJC-0000Nl-Vo for 25247@debbugs.gnu.org; Sat, 31 Dec 2016 12:19:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNNJ3-0003iv-Ht for 25247@debbugs.gnu.org; Sat, 31 Dec 2016 12:19:01 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48357) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNNJ3-0003id-Ei; Sat, 31 Dec 2016 12:18:57 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1306 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cNNJ2-0002U8-Dh; Sat, 31 Dec 2016 12:18:57 -0500 In-reply-to: (message from Elias =?UTF-8?Q?M=C3=A5rtenson?= on Sun, 1 Jan 2017 00:24:59 +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:127635 Archived-At: > From: Elias Mårtenson > Date: Sun, 1 Jan 2017 00:24:59 +0800 > Cc: Tino Calancha , raeburn@raeburn.org, 25247@debbugs.gnu.org > > After doing this, I will see "Foo:0" displayed in the "foo.txt" buffer, and the message "Wrote /home/elias/foo.txt" > updated every second in the minibuffer. > > While this is running (and note that the buffer content has not been updated and still contains just the "Foo:0" > message), I switch to a terminal and cat the content of foo.txt. I can see that the file gets updated and saved > every second, but the content of the buffer is only refreshed when I interact with Emacs (i.e. pressing a key). > > This suggests to me that everything is actually running exactly the way one would expect from a green > threads implementation, where a thread doing a sleep becomes runnable immediatenly after the timer runs > out (as long as the system is otherwise idle at the time). > > It seems as it's simply the buffer content that isn't refreshed properly. I don't understand what you are saying here; it sounds like a contradiction: the file on disk is updated (with presumably the next Foo:%d strings), but the "buffer content isn't refreshed"? Maybe by "buffer content" you mean its display on the screen? Because if the file is updated, the buffer's content must also be updated, as that's what gets written to the file. Right? 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. > 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.