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: Fri, 30 Dec 2016 18:30:05 +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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11443a8a82890e0544ddaf2a X-Trace: blaine.gmane.org 1483093881 27212 195.159.176.226 (30 Dec 2016 10:31:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Dec 2016 10:31:21 +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 Fri Dec 30 11:31:17 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 1cMuSw-0006DZ-67 for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Dec 2016 11:31:14 +0100 Original-Received: from localhost ([::1]:39261 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMuT1-0005Qz-1p for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Dec 2016 05:31:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMuSo-0005PE-Um for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2016 05:31:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cMuSk-0008ON-6H for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2016 05:31:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44163) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cMuSk-0008OE-34 for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2016 05:31:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cMuSj-0002L6-OP for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2016 05:31: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: Fri, 30 Dec 2016 10:31: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.14830938148928 (code B ref 25247); Fri, 30 Dec 2016 10:31:01 +0000 Original-Received: (at 25247) by debbugs.gnu.org; 30 Dec 2016 10:30:14 +0000 Original-Received: from localhost ([127.0.0.1]:59562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMuRy-0002Jw-Ae for submit@debbugs.gnu.org; Fri, 30 Dec 2016 05:30:14 -0500 Original-Received: from mail-wm0-f51.google.com ([74.125.82.51]:38268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMuRw-0002Jg-Dt for 25247@debbugs.gnu.org; Fri, 30 Dec 2016 05:30:12 -0500 Original-Received: by mail-wm0-f51.google.com with SMTP id k184so156781798wme.1 for <25247@debbugs.gnu.org>; Fri, 30 Dec 2016 02:30:12 -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=i3tk5DZBT2kp+hvsFPWPh0WnD+L1k/pq7a09AxgCwQw=; b=lAa/I//sHzU0JgjBFsxn6h+r8NvMg+PdtKr+G3zPofIj7B/N7ltf43HWMFMNwJuavS Z9YDhZiffTD7Cq7BzMGk626JWkZ1V9goEjzJ9S2eQ9EbY87/gTS987ntRy9RWFnqouOZ WjoloCfRG6QnAfHhXpfCOHKp5RZSjuC0g7Sb9GhEjzIkMIAMmnIqlUDiMbdS8sIftumj E6hRjZpTu5s5RwI4V8kDgbW3wX7JElB15LIG/CQt9gFnHKeMZMdg+cjGK7yonipy2skb FFcDGq2Mk5fwkjf4O2X0Dq5jNJUg4yJXw9uAXDJaFz6vbkmU8bvso4khuNr7SpHw7/Pf mCbA== 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=i3tk5DZBT2kp+hvsFPWPh0WnD+L1k/pq7a09AxgCwQw=; b=E2PcpMixBIzvMSikHCIAGaAKcxOSj9ZbfFPl7fviacRuzVBCaCagkPs7dfOlZcuNSN pZT4bDvzvr8z4zhdyi819xl8QEoUUU9m34iY3Ej3j5wDd5DAOCHnOxCHmvvVS/mRMocA C2rVDnEanCL9Ui6DKVA0XARP/3cNLAR9FAq5Pe5mLzzz2Y6y7xEQiHFKsuoZfNXr2PwU PS9nOTb9x1EgNBIrfcnKSQZfIsPgWR2aO8WZwqfj71N+ywMECDxrmhIB0w3bGD3QmN6J wXpPeZR1ubeRDxB3jXiUorZXczzqelU12FXhyBTY9+egDalIXr4le5hTEkSFIJbDH/79 3erQ== X-Gm-Message-State: AIkVDXK6bjtH0i1RM2oxeN6efRHyz1aINQpqgwRE6imlxkw4G6KjkIePK8Dh0oxBbtIxt4n9uZ41wZ4icTbblA== X-Received: by 10.28.136.198 with SMTP id k189mr38385175wmd.24.1483093806579; Fri, 30 Dec 2016 02:30:06 -0800 (PST) Original-Received: by 10.80.135.165 with HTTP; Fri, 30 Dec 2016 02:30:05 -0800 (PST) In-Reply-To: <838tqxu535.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:127579 Archived-At: --001a11443a8a82890e0544ddaf2a Content-Type: text/plain; charset=UTF-8 On 30 December 2016 at 17:41, Eli Zaretskii wrote: Elias, I'd be grateful if you could repeat your thread-related tests > from 2 weeks ago with the latest master (both in "emacs -nw" and in a > GUI session), and see if any of those problems are back. > I did some tests. The C-g issue is still gone. As for the concurrency issues. I have been hammering this thing pretty hard, and no crashes so far. However, I have seen some strange issues. I've been trying to isolate the behaviour, but I don't have any more time to do so at the moment, so I'll just summarise where I am: *Issue 1:* *========* I open IELM in one window, and an empty buffer "z" in another, and type the following: (loop repeat 10 do (make-thread (lambda () (let ((n (random 10))) (with-current-buffer "z" (sleep-for n) (insert (format "Foo:%d\n" n))))))) Here, I'd expect to see the "z" buffer being updated at the corresponding times. I.e. the message "Foo:4" should be displayed after 4 seconds. This is not what I see. Instead the messages appear in batches (i.e. several rows appearing at the same time). *Issue 2:* *========* The following seems to be a problem with lexically bound lambda functions used in a thread. The following example illustrates the problem: (let ((x "test")) (make-thread (lambda () (with-current-buffer "z" (insert x))))) I would expect this to insert "test" into the buffer, but instead nothing happens. Removing the reference to the variable "x" in the lambda makes it work. Regards, Elias --001a11443a8a82890e0544ddaf2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 3= 0 December 2016 at 17:41, Eli Zaretskii <eliz@gnu.org> wrote:

Elias, I'd be grateful if you could repeat your thread-related = tests
from 2 weeks ago with the latest master (both in "emacs -nw" and = in a
GUI session), and see if any of those problems are back.

I did some tests.

The C-g issue = is still gone.

As for the concurrency issues. I ha= ve been hammering this thing pretty hard, and no crashes so far.
=
However, I have seen some strange issues. I've been tryi= ng to isolate the behaviour, but I don't have any more time to do so at= the moment, so I'll just summarise where I am:

Issue 1:
=3D=3D=3D=3D=3D=3D=3D=3D
I open IELM in one window, and an empty buffer "z&quo= t; in another, and type the following:

(loop
=C2=A0 repeat 10
=C2=A0 do (make-thread (lambda ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 (let ((n (random 10)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 (with-current-buffer "z"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (sleep-for n)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (insert (format "Foo:%d\n&q= uot; n)))))))

Here, I'd expect t= o see the "z" buffer being updated at the corresponding times. I.= e. the message "Foo:4" should be displayed after 4 seconds. This = is not what I see. Instead the messages appear in batches (i.e. several row= s appearing at the same time).

Issue 2:<= /b>
=3D=3D=3D=3D=3D=3D=3D=3D

The = following seems to be a problem with lexically bound lambda functions used = in a thread. The following example illustrates the problem:

<= /div>
(let ((x "test"))
=C2=A0 (make-thread (la= mbda ()
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(with-current-buffer "= z"
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(insert x)))))

I would expect this to insert "test&quo= t; into the buffer, but instead nothing happens. Removing the reference to = the variable "x" in the lambda makes it work.

Regards,
Elias
--001a11443a8a82890e0544ddaf2a--