From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Elias =?UTF-8?Q?M=C3=A5rtenson?= Newsgroups: gmane.emacs.bugs Subject: bug#25247: 26.0.50; Concurrency crashes with XLib Date: Sun, 1 Jan 2017 01:28:10 +0800 Message-ID: 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b6d7bea804e570544f7a426 X-Trace: blaine.gmane.org 1483205354 8176 195.159.176.226 (31 Dec 2016 17:29:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Dec 2016 17:29:14 +0000 (UTC) Cc: raeburn@raeburn.org, Tino Calancha , 25247@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 31 18:29:10 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 1cNNSt-0001Bk-UO for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 18:29:08 +0100 Original-Received: from localhost ([::1]:44987 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNNSy-0006lZ-Uc for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 12:29:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNNSs-0006lJ-AI for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 12:29:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNNSo-0008Su-RW for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 12:29:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46274) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cNNSo-0008Sq-Ni for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 12:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cNNSo-0000d3-HQ for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 12:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Elias =?UTF-8?Q?M=C3=A5rtenson?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 Dec 2016 17:29:02 +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.14832052982360 (code B ref 25247); Sat, 31 Dec 2016 17:29:02 +0000 Original-Received: (at 25247) by debbugs.gnu.org; 31 Dec 2016 17:28:18 +0000 Original-Received: from localhost ([127.0.0.1]:33440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNNS6-0000bz-EC for submit@debbugs.gnu.org; Sat, 31 Dec 2016 12:28:18 -0500 Original-Received: from mail-wj0-f181.google.com ([209.85.210.181]:36404) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNNS5-0000bm-2m for 25247@debbugs.gnu.org; Sat, 31 Dec 2016 12:28:17 -0500 Original-Received: by mail-wj0-f181.google.com with SMTP id c11so193087731wjx.3 for <25247@debbugs.gnu.org>; Sat, 31 Dec 2016 09:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=etgc7KC9QJewVFQuWQ8HbVj9zxc0l7x4wo68JdZfjOQ=; b=IedqJrFWaSr5vNJLozrC/X1ugUxDkrPhRjSuq2f6wprqeXTsDOhc3bQhRCC4YOK/Ry tXcCTcdLTxL3K1XqWaqt9poFFF9ENKgy5GNh8HFsQ3dgtywMCz0FhxqDELSviS15sf/u IW+EVDaFhYpx6amXB0VVmG6jWyaeOad7D74sg0hOkLBxweV6ahtSpi8U1PeFvkO5oBVT thVjljoR77Oaql8+RNgzZ6lm2NjHJJ8FIVmSyyJCbI/anhQ28uYgXos47w6OwpP+xiUF P15/MklqY62ds0p7p9wJxbkDsbS6sXTUMQ93Wn+vFBFg9Wq47Tm5F/mMCd45KvxKkmUS ZSUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=etgc7KC9QJewVFQuWQ8HbVj9zxc0l7x4wo68JdZfjOQ=; b=bVwxZiAg6HEzIrHC7j0Tm9O+ScVE19DG3Z68rkJAGDBbKSFBL5SoNTTr+GG/NqszBY WA3FKSJgulUqXWeFWJFLozLGC5ihl4dfgYbe1eKIXRRmGqvXhF/hBo9sVcVmnFP08zsZ JIih1QwT+5qBNIv/yUGqRDN9pd5suHd3dbLGZR7zMNxi8moMAirCQ4DGGRqnKokU3Qse bH8IjnB8ttQVbL4RpYpCFKKdVALSBVThEJL1Ezkx4CYhW1ey9DZQyDozS8umLgsZeTY5 k1J/+Kyv2CXopku2wGMUE9A5QngtKd0wCF8lt9Uhc9xsVFmEhBRSgVsEr5Gu7oKsZ+Aj /Xhg== X-Gm-Message-State: AIkVDXIcgR2uzjwCTE5I+Sx0J7LX3zZLLFxArj+K7T/qY4KD9VR4yuKMx5oV9LMESQ7D148l2D9I1DHDhMeOxA== X-Received: by 10.194.93.37 with SMTP id cr5mr43353622wjb.95.1483205291034; Sat, 31 Dec 2016 09:28:11 -0800 (PST) Original-Received: by 10.80.135.165 with HTTP; Sat, 31 Dec 2016 09:28:10 -0800 (PST) In-Reply-To: <83k2agggp9.fsf@gnu.org> 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:127636 Archived-At: --047d7b6d7bea804e570544f7a426 Content-Type: text/plain; charset=UTF-8 On 1 January 2017 at 01:18, Eli Zaretskii wrote: 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? > That is correct. I meant that the screen has not been updated to reflect the buffer content. > 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". They're all sitting in 'sleep-for' already. > > 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. Thanks, Elias --047d7b6d7bea804e570544f7a426 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= January 2017 at 01:18, Eli Zaretskii <eliz@gnu.org> wrote:
=

I don't u= nderstand 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"?=C2= =A0 Maybe by
"buffer content" you mean its display on the screen?=C2=A0 Becaus= e if the
file is updated, the buffer's content must also be updated, as that'= ;s
what gets written to the file.=C2=A0 Right?

=
That is correct. I meant that the screen has not been updated to refle= ct the buffer content.
=C2=A0
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.=C2=A0 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 t= o when you say "ready to run". There are of course more threads, = but none of them should be "ready to run". They're all sittin= g in 'sleep-for' already.
=C2=A0
> Interestingly enough, the minibuffer me= ssage does get updated.

Displaying minibuffer messages uses a separate entry to redisplay, a= nd
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 everythi= ng work exactly the way I'd expect it to.

I guess doing that is perfectly acc= eptable and understandable once one has had the benefit of someone explaini= ng it to him, like in this case. That said, it would be nice if I didn'= thave to.

Thanks,
Elias
--047d7b6d7bea804e570544f7a426--