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 02:16:41 +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> <83h95kgehu.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114b1378ffd17c0544f8511c X-Trace: blaine.gmane.org 1483208235 20733 195.159.176.226 (31 Dec 2016 18:17:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Dec 2016 18:17:15 +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 19:17: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 1cNODL-0004Cd-Bc for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 19:17:07 +0100 Original-Received: from localhost ([::1]:45073 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNODQ-0004XX-8L for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 13:17:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNODJ-0004XL-V5 for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:17:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNODG-00020A-RR for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:17:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46291) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cNODG-0001zo-Nk for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cNODG-0001kA-AX for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 13:17: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 18:17: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.14832082106681 (code B ref 25247); Sat, 31 Dec 2016 18:17:02 +0000 Original-Received: (at 25247) by debbugs.gnu.org; 31 Dec 2016 18:16:50 +0000 Original-Received: from localhost ([127.0.0.1]:33457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNOD3-0001jh-VS for submit@debbugs.gnu.org; Sat, 31 Dec 2016 13:16:50 -0500 Original-Received: from mail-wm0-f53.google.com ([74.125.82.53]:38440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNOD1-0001jR-OT for 25247@debbugs.gnu.org; Sat, 31 Dec 2016 13:16:48 -0500 Original-Received: by mail-wm0-f53.google.com with SMTP id k184so182678176wme.1 for <25247@debbugs.gnu.org>; Sat, 31 Dec 2016 10:16:47 -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=6K9bnLpaR9Be6KCOa4uK9W1J6HcmLjYoVBqIOFcbSVU=; b=Oa7to/ssZqkVuIcnQCzD6AXRDrU2499/jzHSMYXZqi8epZxwCeO35vPkwaHO0+/Wl2 1928GAQDXtpb4WCh/ntWIgUazOJirI1kku7voJeRukb3JZc1xZWC8TnvwOcbnXUz36Vg ddMH3hDxv9TKniYjk8NiT3S2gutKgnz//FMaZ2MZOiP8oQcWTaRr6X6J+PGPWj7QTKMb ovfiTO8tANUp0iTGXJPXG6WO6/uvkLfyrD/0lqh8HKgKHxpmya+9pXUWCA6s86Ko/ASz dXpXJ00XoOpKSzhcmGDllo34ML6g26Dru1MaQTZX4Eg1igxr2MwlCHg4QlbHeR6QkVAY jvGw== 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=6K9bnLpaR9Be6KCOa4uK9W1J6HcmLjYoVBqIOFcbSVU=; b=AlRHB+GXVOry/I5K+T+DKUpZ8ZXn1OH+VjDEhRowe6YYmJsDU1MR4O93i3jcgS9u+b Jv0SXgaMOMkK2KC7KHcYkY7Vf6PwMCmcjti7XRtKUCaJqdbDJ4wCCPaEZb9g6p6b5gEl OkVU1y008mE6CYn888shS37T0xWZbtUUbjdpBNsYBEv7mlhNTamBQH3tJ0flz5hu8pwg AZIju4D/A3QZOrvPsStoH8jKSl58P7f5XFBFDTHe/qr69V1eb93CM0sj1r9jaOHG8Obu 24nt+ngLQSZkgbl7V9SzzWrg1fJLEEvA2J/z/geJqUXuaf/2S5H1S7mNN7DyKajhmafo eIEA== X-Gm-Message-State: AIkVDXKY4jrNagPuhHh58F6U8+YXGphQ4JE+ePlBJ5NQnJv+uIPUVND2pA7kOFS9m3DFqYx2X/ZfSUqb9o2vig== X-Received: by 10.28.226.139 with SMTP id z133mr50155923wmg.139.1483208201849; Sat, 31 Dec 2016 10:16:41 -0800 (PST) Original-Received: by 10.80.135.165 with HTTP; Sat, 31 Dec 2016 10:16:41 -0800 (PST) In-Reply-To: <83h95kgehu.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:127639 Archived-At: --001a114b1378ffd17c0544f8511c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1 January 2017 at 02:06, Eli Zaretskii wrote: > > From: Elias M=C3=A5rtenson > > 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. > In this case, the thread died, and all other threads are idle. Wouldn't this trigger a redisplay? 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. 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 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. > Fair enough. I guess the introduction of threads will make the redisplay function more important than it has been in the past. Regards, Elias --001a114b1378ffd17c0544f8511c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= January 2017 at 02:06, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Elias M=C3=A5rtenson <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
>
>=C2=A0 The display on the screen will only chan= ge if Emacs enters redisplay.
>=C2=A0 If you see the file's contents change, but the display on th= e screen
>=C2=A0 doesn't reflect that, it means Emacs does not get a chance t= o perform
>=C2=A0 redisplay, because it doesn't become idle in any of the thre= ads that
>=C2=A0 are active. Which could be the case, since every time a running<= br> >=C2=A0 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.=C2=A0 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, an= d all other threads are idle. Wouldn't this trigger a redisplay?
<= div>
Those which are still waiting = for their sleep period to expire will
not run, because they are inside the pselect call.=C2=A0 Only the threads whose sleep period already expired are "ready to run", because th= ey
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.

If that was inde= ed 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.
=C2= =A0
> 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 i= f I didn' thave to.

It's perfectly normal for Emacs not to redisplay when some Lisp = is
running.=C2=A0 That is what happens here, except that "some Lisp"= in this
case can come from another thread.

Fair enough. I gues= s the introduction of threads will make the redisplay function more importa= nt than it has been in the past.

=
Regards,
Elias
--001a114b1378ffd17c0544f8511c--