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: Sat, 31 Dec 2016 23:34:33 +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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1145a83631a5cc0544f60eb5 X-Trace: blaine.gmane.org 1483198516 1314 195.159.176.226 (31 Dec 2016 15:35:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Dec 2016 15:35:16 +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 16:35:12 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 1cNLga-000829-NT for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 16:35:08 +0100 Original-Received: from localhost ([::1]:44533 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNLgf-0004hJ-Gk for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 10:35:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNLgY-0004fn-Bc for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 10:35:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNLgU-00026r-6y for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 10:35:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46211) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cNLgU-00026d-40 for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 10:35:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cNLgT-0006Nf-On for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 10:35:01 -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 15:35: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.148319848224498 (code B ref 25247); Sat, 31 Dec 2016 15:35:01 +0000 Original-Received: (at 25247) by debbugs.gnu.org; 31 Dec 2016 15:34:42 +0000 Original-Received: from localhost ([127.0.0.1]:33377 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNLgA-0006N4-Jk for submit@debbugs.gnu.org; Sat, 31 Dec 2016 10:34:42 -0500 Original-Received: from mail-wm0-f49.google.com ([74.125.82.49]:38363) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNLg8-0006Mp-Eq for 25247@debbugs.gnu.org; Sat, 31 Dec 2016 10:34:40 -0500 Original-Received: by mail-wm0-f49.google.com with SMTP id k184so180597494wme.1 for <25247@debbugs.gnu.org>; Sat, 31 Dec 2016 07:34:40 -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=ppJYKhGrxr3AuXPMUSnn+8fNahfpb6FW5yxHXc6fcZU=; b=BEdG/86hsPDhvWqv0P/z7rJI/4X2D3ZHw2abhArMrNoy26PTNUjFcTGRomNtfP5JJK 6+wvpITJOXRS+k0JaXds91OyVl6dFPwjfNsO2VWdUV+cvoaJV8Jtn09wrg7aOAna7AoC ONv4kteSpqGVDS+0DTGX3wnrBPc1ZDfr2IMTgxBydv72B1JpIxT8KHhy3j1dATfG9gWX eaJRDQSF/XaOk7Rd/ksTEdli7aQfVI8HkuSpU3J0ALPlrdWWm0egvdvNa82Xnbd47rvX IPDjvfPOVQFoKPOYqhGePd3AyXzQVQhA6vr2QfpW6a24RX2+Hx72KnCGO3F+/ajhJqCM 37VA== 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=ppJYKhGrxr3AuXPMUSnn+8fNahfpb6FW5yxHXc6fcZU=; b=EljP7bbrHftJ953sdP7kmTtbwmH3FOtbUih1vkbFizV9WgssCdDJcydZJEud5RiogT uzxqIQXxH4syBIRihGXyzRjO46INHGCx0Cm8Zzwlsuc1zJUJ2OzPw9wIB0JIzepQujor 6fVV9PjtBeirqaLlrnaqCpBA6K7zsQUSyIsiW6Hj5wSh+HNa6A2wj7SgHQSWubI9+63P Llaqs/VKxu59Mzfk/o0VhQ94+HNDFy3cWeZ1Sh+20GukR72Z3uxaZqgS17v8Q4dLgFVu eICawSMG2IM9h80zNujkGhYiXAkES9SiKTjONiIAWKdS54Ur7GoGk0QNN2Xyryi51hzV DyzQ== X-Gm-Message-State: AIkVDXJ6KpCGP/YjGo9VtER2lyJSaorP9yktHg0/+hDX+SD9wnG4pI4RGDF3TBkgx+w6oDSeG1jGVb4/cEuF8g== X-Received: by 10.28.20.70 with SMTP id 67mr41982106wmu.102.1483198474329; Sat, 31 Dec 2016 07:34:34 -0800 (PST) Original-Received: by 10.80.135.165 with HTTP; Sat, 31 Dec 2016 07:34:33 -0800 (PST) In-Reply-To: <83tw9kgxyy.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:127626 Archived-At: --001a1145a83631a5cc0544f60eb5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 31 December 2016 at 19:05, Eli Zaretskii wrote: > > From: Elias M=C3=A5rtenson > > Date: Fri, 30 Dec 2016 19:21:08 +0800 > > Cc: Tino Calancha , raeburn@raeburn.org, > 25247@debbugs.gnu.org > > > > One interesting fact is that if I replace =E2=80=98sleep-for=E2=80=99 w= ith =E2=80=98sit-for=E2=80=99, > then the updates come at exactly the expected > > time. But only as long as blink-cursor-mode is turned on, right? If you > turn it off before running the experiment, sit-for behaves the same as > sleep-for, right? > 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. 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. 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. Regards, Elias --001a1145a83631a5cc0544f60eb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 3= 1 December 2016 at 19:05, Eli Zaretskii <eliz@gnu.org> wrote:
=
> From: Elias M=C3=A5r= tenson <lokedhs@g= mail.com>
> Date: Fri, 30 Dec 2016 19:21:08 +0800
> Cc: Tino Calancha &l= t;tino.calanch= a@gmail.com>, raeburn@raeburn.org, 25247@debbugs.gnu.org
>
> One interesti= ng fact is that if I replace =E2=80=98sleep-for=E2=80=99 with =E2=80=98sit-= for=E2=80=99, then the updates come at exactly the expected
> time.
But only as long as blink-cursor-mode is turned on, right?=C2=A0 If yo= u
turn it off before running the experiment, sit-for behaves the same as
sleep-for, right?

I always turn off bli= nk-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 bli= nk-cursor-mode on, it updates during the blinking phase just as you suggest= ed it would.
=C2=A0
When blink-cursor-mode is ON, it supplies 2 events each secon= d, and
that allows the threads that finished waiting to acquire the global
lock and insert the string.=C2=A0 Otherwise, the threads wait for the
global lock and do the insertions at the end.

I can only con= clude that one of my millions of customisations triggers a refresh at some = interval that is rougly 4-5 seconds.

I also discov= ered that the event is actually triggered (i.e. the call to sleep-for actua= lly finishes on-time but it's just the buffer content that are not upda= ted). That makes things a lot more clear for me.

N= ow, 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 s= ome way for Elisp code to force the repaint of a buffer.

Regards,
Elias
--001a1145a83631a5cc0544f60eb5--