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 00:24:59 +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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e012285be88c4720544f6c26d X-Trace: blaine.gmane.org 1483201576 12684 195.159.176.226 (31 Dec 2016 16:26:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Dec 2016 16:26: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 17:26:13 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 1cNMTz-0002ZA-3h for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 17:26:11 +0100 Original-Received: from localhost ([::1]:44682 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNMU4-0003KF-4L for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Dec 2016 11:26:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNMTv-0003ID-6P for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 11:26:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNMTq-0007Ns-Dz for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 11:26:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46229) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cNMTq-0007Ng-Aq for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 11:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cNMTq-0007Zb-0u for bug-gnu-emacs@gnu.org; Sat, 31 Dec 2016 11:26: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 16:26: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.148320150729047 (code B ref 25247); Sat, 31 Dec 2016 16:26:01 +0000 Original-Received: (at 25247) by debbugs.gnu.org; 31 Dec 2016 16:25:07 +0000 Original-Received: from localhost ([127.0.0.1]:33395 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNMSx-0007YR-5y for submit@debbugs.gnu.org; Sat, 31 Dec 2016 11:25:07 -0500 Original-Received: from mail-wj0-f174.google.com ([209.85.210.174]:33032) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNMSv-0007Xu-OY for 25247@debbugs.gnu.org; Sat, 31 Dec 2016 11:25:06 -0500 Original-Received: by mail-wj0-f174.google.com with SMTP id tq7so160304748wjb.0 for <25247@debbugs.gnu.org>; Sat, 31 Dec 2016 08:25:05 -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=JXuFAyp3acgKaI4B8yLrvdEah/xjLQ8wGtxc8tC22d0=; b=Iw1z2hAEeliv4s61OFaPb10sfcsogPIn2rZ8T883STxC310NS+HBUF6zXLajBxy4Zp ITcU6Z4jLzM1WvenfmZaNve1QN3/uLm0Kt6ZTVIUKgPSuAsGUjblLgiqrzVbGVd2c2MW zVyiJoMzc+OHDsCHSS/8RHlNekksDEHW+08eFg41F0jy9fdJUP9Qp6TL96sALsWMLD5I ubN2l5+BiIA3yz90AgU6PhP9bAet1bT0JvMbsB411sZIbgo5U/iZDybmXxvDlkyDQmVN y3sVMKTbgQgoQNHKBWKYDo3xZc6iB5sOEFv54G4WvGy8QJdxFBCn3rtZMKSfgCFlZuWI sz+w== 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=JXuFAyp3acgKaI4B8yLrvdEah/xjLQ8wGtxc8tC22d0=; b=r3JWCTg64p5IhTPzE++pzhzQUfwnXUZzkvdLcw6NhKrmMUQhCD9XiNeojxMBbQniY/ /K28ODARh0EdnfAbczGwnkFMRv3gDUO0KjmecKRJINOxNgXoYXG2AsIIFCCIuVD+hmgZ Jdubdb9DAvFvrNg96e8FO18ipb8Cl8NlpZ+UKeHWqCuCJQO4pnEZSlO7yglvP6GN1vJX bU+CqgDpX4g9mqMBnbaaWew6eR0mHi4AoBfwo4x48Wcdg9UME/sJiR/rAf6WD7FIfckG ehG/zzOyEQ3ASwtL8NpaDNxgnUr7Ro3V5QopvLy4HJoaPm2iiX/d0VTZ8l8ZTTgNjpP9 A0yA== X-Gm-Message-State: AIkVDXKTwcLYG3dG9K7vQMeHfoUIKwoDyWzcOQtZtXKxQ8VOMSxh5l9DLY1u1flz/UW8WO2MynONpZz89K0GFA== X-Received: by 10.194.145.197 with SMTP id sw5mr44200755wjb.156.1483201499937; Sat, 31 Dec 2016 08:24:59 -0800 (PST) Original-Received: by 10.80.135.165 with HTTP; Sat, 31 Dec 2016 08:24:59 -0800 (PST) In-Reply-To: <83mvfcgkqu.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:127630 Archived-At: --089e012285be88c4720544f6c26d Content-Type: text/plain; charset=UTF-8 On 31 December 2016 at 23:51, Eli Zaretskii wrote: I think the update on screen is indeed immediate, it's just that > insertion doesn't happen immediately after the sleep period ended. > I don't think it is. I ran the following test to check the behaviour: Start 'emacs -Q' Split into two windows, one with the file ~/foo.txt (empty) and the other with IELM In the IELM buffer type: (setq lexical-binding t) (blink-cursor-mode -1) (dotimes (i 10) (let ((j i)) (make-thread (lambda () (with-current-buffer "foo.txt" (sleep-for j) (insert (format "Foo:%d\n" j)) (write-file "~/foo.txt")))))) 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. Interestingly enough, the minibuffer message does get updated. Regards, Elias --089e012285be88c4720544f6c26d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 3= 1 December 2016 at 23:51, Eli Zaretskii <eliz@gnu.org> wrote:

I think the update on screen is indeed immediate, it's just tha= t
insertion doesn't happen immediately after the sleep period ended.

I don't think i= t is. I ran the following test to check the behaviour:

Start 'emacs -Q'

Split i= nto two windows, one with the file ~/foo.txt (empty) and the other with IEL= M

In t= he IELM buffer type:

=C2=A0(setq lexical-binding t)
=C2=A0(blink-cursor-mode = -1)
=C2=A0(dotimes (i 10)
(let ((j i))
=C2=A0 (make-thread (lambda ()<= /div>
=C2=A0(w= ith-current-buffer "foo.txt"
=C2=A0 =C2=A0(sleep-for j)
=C2=A0 =C2= =A0(insert (format "Foo:%d\n" j))
=C2=A0 =C2=A0(write-file "~= /foo.txt"))))))

After doing this, I will see "Foo:0" displa= yed in the "foo.txt" buffer, and the message "Wrote /home/el= ias/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 con= tent of foo.txt. I can see that the file gets updated and saved every secon= d, but the content of the buffer is only refreshed when I interact with Ema= cs (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, wher= e 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. Interestingly = enough, the minibuffer message does get updated.

Regards,
Elias
--089e012285be88c4720544f6c26d--