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 19:21:08 +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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b6d7bea05bb590544de665c X-Trace: blaine.gmane.org 1483096943 10902 195.159.176.226 (30 Dec 2016 11:22:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Dec 2016 11:22:23 +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 12:22:16 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 1cMvGC-00012o-5O for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Dec 2016 12:22:08 +0100 Original-Received: from localhost ([::1]:39383 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMvGG-0002MO-JX for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Dec 2016 06:22:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36261) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMvGA-0002MJ-1M for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2016 06:22:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cMvG6-0005AF-TF for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2016 06:22:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44183) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cMvG6-0005AA-Og for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2016 06:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cMvG6-0003Wl-Go for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2016 06:22: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: Fri, 30 Dec 2016 11:22: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.148309687613495 (code B ref 25247); Fri, 30 Dec 2016 11:22:02 +0000 Original-Received: (at 25247) by debbugs.gnu.org; 30 Dec 2016 11:21:16 +0000 Original-Received: from localhost ([127.0.0.1]:59582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMvFL-0003Vb-MQ for submit@debbugs.gnu.org; Fri, 30 Dec 2016 06:21:15 -0500 Original-Received: from mail-wj0-f175.google.com ([209.85.210.175]:33476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMvFK-0003VP-CM for 25247@debbugs.gnu.org; Fri, 30 Dec 2016 06:21:14 -0500 Original-Received: by mail-wj0-f175.google.com with SMTP id tq7so139300466wjb.0 for <25247@debbugs.gnu.org>; Fri, 30 Dec 2016 03:21:14 -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=MaAMcJQpyL8HoDNP4SN0myg0+czXfjoHitlsrPOnooo=; b=IEy5skEMFOxa98ehkV6HdfbYIsT07Z/F/XIq/EQDcfTXZW2/L0yiMrAe9pB3TKwHb8 wwuRoJMm3fzCC25fqBHcITe1tjDJYt2S1Tm+5D3JMn0iAWoCcslelK69I5qPiu4MK3iC DizptyoOEbLnkhx8cqOu757S8qwYptd6o3nOEyqAvjkNphsxePBzOuF+Qco8awAB2xR7 KzEYCdTFRtBvW3is/4OBdqZ7wSeedEhL5/9QrNKiPUWK4aeRjHGMrUkpKGLR3qrFu51k HFheM21RpzX31D8UynM4+o1pBI8HOa+zK68ESmexaUdIlxC9lDm6oIbJywKc2ijConCY tOnw== 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=MaAMcJQpyL8HoDNP4SN0myg0+czXfjoHitlsrPOnooo=; b=JSxmd2k/F6DPoIaaY8RFKmFFIacNPjJ5AdXNdadDywppuiO6wW9UXpU3prCQZNWmp/ HtfU8e9ug4ksUbXNXmMfVBQN5oPsbS8JYNXy2EvUxaewO/l3RXs1fxDmgVxKQIcZoaYM +9znp/v1ToOHO2va+5bd5Mt7lSMBGw/jVE5rIUd6Q+RFEHOEDVLZHRa5a4C119J9Jl5T Il2QTQySneT91XR3tlj51FhD8v/eZ2LwsRf6KheqytiCaS1rpY6e1FBnhv5CYH+3Bjn6 8vTI8CaIT0KBdclTeWnfDQiJepSRLXVU1Jz2FwGt0KdB/2SMr2QmYQ73y7MuEQ9JzAVU hlXg== X-Gm-Message-State: AIkVDXLFutsbuHOxmi3IV9QpaS8yFMuFma9ATSQM1rcWrenPv9dU1iiq7jqR6XXc2mB5TFrtPJvZ8I2OZ0b5UA== X-Received: by 10.194.93.37 with SMTP id cr5mr39218050wjb.95.1483096868631; Fri, 30 Dec 2016 03:21:08 -0800 (PST) Original-Received: by 10.80.135.165 with HTTP; Fri, 30 Dec 2016 03:21:08 -0800 (PST) In-Reply-To: <834m1lu16d.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:127581 Archived-At: --047d7b6d7bea05bb590544de665c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 30 December 2016 at 19:05, Eli Zaretskii wrote: > 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 correspondi= ng > > times. I.e. the message "Foo:4" should be displayed after 4 seconds. Th= is > > is not what I see. Instead the messages appear in batches (i.e. several > > rows appearing at the same time). > > And what do the messages that appear together say in the %d part? Do > they all show the same value? > No. They show wildly different values. For example, during one test, after roughly 8 seconds, I got 7 or so messages with number ranging from 2 to 8. One interesting 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. In other words, the unpredictable behaviour where keypresses would randomly make the =E2=80=98s= it-for=E2=80=99 expire doesn't happen anymore. > 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 nothi= ng > > happens. Removing the reference to the variable "x" in the lambda makes > it > > work. > > Isn't the above expected? If not, why not? > Never mind. This one was caused by me. Please ignore it. The problem was that =E2=80=98lexical-binding=E2=80=99 was set to nil in my= IELM buffer. Regards, Elias --047d7b6d7bea05bb590544de665c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 3= 0 December 2016 at 19:05, Eli Zaretskii <eliz@gnu.org> wrote:

> I open IELM in one window, and an empty buffer "z" in = another, and type the
> following:
>
> (loop
>=C2=A0 =C2=A0repeat 10
>=C2=A0 =C2=A0do (make-thread (lambda ()
>=C2=A0 =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 =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 =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 =C2=A0(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. severa= l
> rows appearing at the same time).

And what do the messages that appear together say in the %d part?=C2= =A0 Do
they all show the same value?

No. They = show wildly different values. For example, during one test, after roughly 8= seconds, I got 7 or so messages with number ranging from 2 to 8.

One interesting fact is that if I replace =E2=80=98sleep-fo= r=E2=80=99 with =E2=80=98sit-for=E2=80=99, then the updates come at exactly= the expected time. In other words, the unpredictable behaviour where keypr= esses would randomly make the =E2=80=98sit-for=E2=80=99 expire doesn't = happen anymore.

> The following seems to be a problem with lexically bound lamb= da functions
> used in a thread. The following example illustrates the problem:
>
> (let ((x "test"))
>=C2=A0 =C2=A0(make-thread (lambda ()
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (with-cu= rrent-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" into the buffer, but in= stead nothing
> happens. Removing the reference to the variable "x" in the l= ambda makes it
> work.

Isn't the above expected?=C2=A0 If not, why not?

Never mind. This one was caused by me. Please ignore i= t.

The problem was that =E2=80=98lexical-binding= =E2=80=99 was set to nil in my IELM buffer.

Regard= s,
Elias
--047d7b6d7bea05bb590544de665c--