From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Sun, 09 Oct 2016 19:59:09 -0700 Message-ID: References: <87wq97i78i.fsf@earlgrey.lan> <86k2dk77w6.fsf@molnjunk.nocrew.org> <9D64B8EA-DB52-413D-AE6A-264416C391F3@iotcl.com> <83int1g0s5.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1476071184 9673 195.159.176.226 (10 Oct 2016 03:46:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 10 Oct 2016 03:46:24 +0000 (UTC) User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (darwin) Cc: lars@nocrew.org, Toon Claes , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 10 05:46:19 2016 Return-path: Envelope-to: ged-emacs-devel@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 1btRXK-0007tS-5S for ged-emacs-devel@m.gmane.org; Mon, 10 Oct 2016 05:45:58 +0200 Original-Received: from localhost ([::1]:47166 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btRXI-00027a-EP for ged-emacs-devel@m.gmane.org; Sun, 09 Oct 2016 23:45:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btQso-0008GZ-I3 for emacs-devel@gnu.org; Sun, 09 Oct 2016 23:04:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btQsm-0006V8-6p for emacs-devel@gnu.org; Sun, 09 Oct 2016 23:04:05 -0400 Original-Received: from mail-pa0-x22c.google.com ([2607:f8b0:400e:c03::22c]:36074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btQse-0006Qk-ID; Sun, 09 Oct 2016 23:03:56 -0400 Original-Received: by mail-pa0-x22c.google.com with SMTP id ry6so46413354pac.3; Sun, 09 Oct 2016 20:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mail-followup-to:mime-version; bh=7gZeMm/itty5Q5bcRZ0RfFdhYy/cz3I+KE/9gqZaBF8=; b=V5Y01+r2I49E6u22NHvKL8qxID9tK5z8X4vONsy2bwtsueR0pv9t6zPCIlPvjP4J4p q+DQ2Do/hFvbL0O3NwPxKWb4Gg4OzpP38FVtFejVktocs2tF22ZcdhBtP0MMHKiV9CqQ XYjfNu7wXT8oY1FpAIF4BdxtTPtDJynwhi/DwzE7sRrpXPA5+JnYlCvqPPPmTCZd/3A7 F93Gy7J1l8etjqCq4ykFgWd5RKjJHBLyXYgxUOkm6r+x0nQn1cd8EzfJeyyLZqYrSG94 7HBZ4FljxwGSkGUm/kbXCeXgCMJ1pmQq5SSgNNfyyz4kL40bObrm5CoohdAt3JE53RX1 bYyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:in-reply-to:date:message-id :references:user-agent:mail-followup-to:mime-version; bh=7gZeMm/itty5Q5bcRZ0RfFdhYy/cz3I+KE/9gqZaBF8=; b=lahwI7+IjyKAAEXm0a2Sa3a+z1j46A5KHP2pH5GZYHfFGN4dq8vwiF4IV80oI2DPgS v4PZi0RODZWLIqE/Z/zph9uhXaG1OlMZnNU4moMeeEe3jXZtp4tMNSLUKZUZo+CLi8zT ln5UwavrWsFES21US8Ha+2siZSav/aFUwb6/QUVbdb9rQ39CmUkRfDGNyjufTCenmyE5 FFyDiWGSlK6gG219pUBafJfKObXKi7JBxcJWmEAkR5jzSET/7EqNBHzqwIwTNBC3aasQ /+O6++CZLaYozVeqnvJM8Ty8U+QpaAg0HbWHAEySbzAq2Z0/FQzttyVcJbO+03fMlPF9 eAxQ== X-Gm-Message-State: AA6/9RkBI6zfQp/7vCMCkSdSoBWUDVCxrupNWmGFOqkLjddzzhruMKwDJAxitz+SeDzMSg== X-Received: by 10.66.136.36 with SMTP id px4mr16324457pab.167.1476068635633; Sun, 09 Oct 2016 20:03:55 -0700 (PDT) Original-Received: from Vulcan.local (76-234-69-149.lightspeed.frokca.sbcglobal.net. [76.234.69.149]) by smtp.gmail.com with ESMTPSA id ak3sm49220657pad.19.2016.10.09.20.03.52 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 09 Oct 2016 20:03:53 -0700 (PDT) X-Google-Original-From: "John Wiegley" Original-Received: by Vulcan.local (Postfix, from userid 501) id BA6B42D4D034; Sun, 9 Oct 2016 20:03:52 -0700 (PDT) In-Reply-To: <83int1g0s5.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Oct 2016 15:33:14 +0300") Mail-Followup-To: Eli Zaretskii , Toon Claes , lars@nocrew.org, emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400e:c03::22c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:208130 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable >>>>> Eli Zaretskii writes: > There's already a concurrency branch in the Emacs repository. It needs so= me > work before it could be merged to master, so if there are people here who > wants this badly enough, I suggest that they continue work almost done by > Tom Tromey, who developed that branch, instead of starting anew. I think it needs more than just a little work. I spoke to Tom on the phone last year, and we both agreed it's not a foregone conclusion that that bran= ch represents the right way of approaching concurrency for an application like Emacs. In general, users don't want programmatic concurrency. What they want is for Emacs not to freeze up after they've asked it to do something. And there are other ways of achieving this end -- depending on the nature of the problem = -- than making concurrency a first-class citizen, with the innumerable problems it brings. I fear we'd be debugging subtle interaction issues for the rest = of our lives if we just merged Tom's branch in today. It implements a Java-sty= le form of concurrency, dependent on mutexes and locking to achieve coherency, which is fiendishly difficult to get right, even if you confine its use to just a few small tasks. The hardest bug I ever debugged in my life was a concurrency bug; the second hardest wasn't even close (and thankfully, I didn't try to solve it at the same time). I'd much rather we re-examine the goals we want to achieve with concurrency, an then ask if there are other ways to get there besides, well, concurrency. For example, if we had a lightweight forking mechanism with transparent communication between sub-ordinate processes (think async.el, but in C and highly efficient), I think we could achieve what users want, without the downsides developers don't want. Even the popular web browsers are moving in this direction, since it gives a similar effect to threading, but without as many of the downsides; or take the popularity of the Actor model, used to reduce the coherency problem down to just mailboxes. The reason I love Haskell for its STM concurrency (software transactional memory) is that it makes certain classes of problems impossible to express.= I believe we would need a mechanism like that for Emacs Lisp, so no one ever = has to hunt down cyclic mutex locks, or reference counts, or why two operations that should be atomic aren't. I'd rather have a single-threaded Emacs for a quite a while longer before inviting these sorts problems into our lives. =2D-=20 John Wiegley GPG fingerprint =3D 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJX+wP9AAoJEMFE2PTxn+YwhS4L+wZDAcKqx0dkVxQhHCgzT/IL 6Vg8GpkHSpK7tfK+xuwawuyOywYTJGTSIi3emgN9fueB6MZIQmlEClC9nJv/zN0n uTI8L0sZHYLl/7YfIgt6rm5lOY0uxLPSE/aqOYtE7hGOhQJ7y3vKOhfceishytsb CpUGCNPFdyvM1O67Xx59JLKfCX7i3fIVtEpR8qpX5ch7CrHQC1we01lhjZ7MphZz xs85KWEImtZSK6pDacZez8+5CaMoFdPkvhK8y33ZIlGXbW/YLJBtPTTOXnxMX4pa wE3YiL00CzBN9txSQWaC61P1/uWbMo9ZejAgaoMPzSf81V5yPwGjENyMRXRm05qQ sz+KFyLLRC7Bn7sOhdSeDDM07RB6lDn+6wXWEjrUW9zCrm+3wzqxjxlSXAAq7uWU +dfFr4mtKx2hzCHaqC4VcC52yx7RepxhbHTsW8L9wEffnfg9Z6oHnlQboC8wuRYp H2tdD+q3gO3VBOTICtepEH4vOvUOggAmOqehx7K5/A== =C2wr -----END PGP SIGNATURE----- --=-=-=--