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 17:51:21 +0200 Message-ID: <83mvfcgkqu.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> 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 1483199534 14408 195.159.176.226 (31 Dec 2016 15:52:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Dec 2016 15:52:14 +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 16:52: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 1cNLx1-0002eH-4U for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 16:52:07 +0100 Original-Received: from localhost ([::1]:44604 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNLx6-0007LB-2G for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 10:52:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34520) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNLwz-0007L6-Td for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 10:52:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNLww-0001gS-0v for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 10:52:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46216) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cNLwv-0001gC-T8 for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 10:52:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cNLwv-0006ll-Md for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 10:52: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 15:52: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.148319949525984 (code B ref 25247); Sat, 31 Dec 2016 15:52:01 +0000 Original-Received: (at 25247) by debbugs.gnu.org; 31 Dec 2016 15:51:35 +0000 Original-Received: from localhost ([127.0.0.1]:33382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNLwV-0006l2-5g for submit@debbugs.gnu.org; Sat, 31 Dec 2016 10:51:35 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:43476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNLwT-0006kq-TT for 25247@debbugs.gnu.org; Sat, 31 Dec 2016 10:51:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNLwK-0001FQ-QR for 25247@debbugs.gnu.org; Sat, 31 Dec 2016 10:51:28 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47428) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNLwK-0001FM-N7; Sat, 31 Dec 2016 10:51:24 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1239 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cNLwJ-0001SP-AD; Sat, 31 Dec 2016 10:51:24 -0500 In-reply-to: (message from Elias =?UTF-8?Q?M=C3=A5rtenson?= on Sat, 31 Dec 2016 23:34:33 +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:127627 Archived-At: > From: Elias Mårtenson > Date: Sat, 31 Dec 2016 23:34:33 +0800 > Cc: Tino Calancha , raeburn@raeburn.org, 25247@debbugs.gnu.org > > I always turn off blink-cursor, but just to ensure that I was correct, I tried to reproduce with -Q and that was > very revealing. > > With -Q and only turning off blink-cursor-mode, I get no updates until I hit a key. With blink-cursor-mode on, it > updates during the blinking phase just as you suggested it would. > > When blink-cursor-mode is ON, it supplies 2 events each second, and > that allows the threads that finished waiting to acquire the global > lock and insert the string. Otherwise, the threads wait for the > global lock and do the insertions at the end. > > I can only conclude that one of my millions of customisations triggers a refresh at some interval that is rougly > 4-5 seconds. Look at timer-idle-list for possible illumination. Failing that, look at timer-list. When timers are active, wait_reading_process_output (which is where implicit thread switches are triggered) reduces the timeout values it uses when it calls thread_select/pselect. It does so in order not to miss the time when the next timer is set to expire. That makes the Emacs main loop crank at higher frequency, and each cycle brings another chance for another thread to start running, because thread_select starts by releasing the global lock. So what a frequent timer does is it allows threads that finished waiting in sit-for to run the rest of their code, which is insert the string into the buffer. > I also discovered that the event is actually triggered (i.e. the call to sleep-for actually finishes on-time but it's > just the buffer content that are not updated). That makes things a lot more clear for me. Yes, because the thread which finished its sleep time goes on to reacquire the global lock, and waits for that to be come available. > Now, this begs the question: Is this the appropriate behaviour? It would be very nice if buffer updates made by > threads were immediately updated on the screen. If that is not possible for some reason, I think there should > be some way for Elisp code to force the repaint of a buffer. I think the update on screen is indeed immediate, it's just that insertion doesn't happen immediately after the sleep period ended.