From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Concurrency, again Date: Tue, 25 Oct 2016 13:22:42 +0000 Message-ID: References: <87wq97i78i.fsf@earlgrey.lan> <86k2dk77w6.fsf@molnjunk.nocrew.org> <9D64B8EA-DB52-413D-AE6A-264416C391F3@iotcl.com> <83int1g0s5.fsf@gnu.org> <83twckekqq.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114b30f8db8d76053fb0677b X-Trace: blaine.gmane.org 1477402036 24907 195.159.176.226 (25 Oct 2016 13:27:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2016 13:27:16 +0000 (UTC) Cc: lars@nocrew.org, toon@iotcl.com, emacs-devel@gnu.org To: Eli Zaretskii , John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 15:27:12 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 1bz1kl-0003hq-4D for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 15:26:55 +0200 Original-Received: from localhost ([::1]:54485 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz1kn-0007XI-HA for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 09:26:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz1h3-0004NA-F0 for emacs-devel@gnu.org; Tue, 25 Oct 2016 09:23:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz1gy-0006Pi-NK for emacs-devel@gnu.org; Tue, 25 Oct 2016 09:23:05 -0400 Original-Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]:33713) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bz1gs-0006Nl-Dc; Tue, 25 Oct 2016 09:22:54 -0400 Original-Received: by mail-wm0-x22e.google.com with SMTP id c78so25533036wme.0; Tue, 25 Oct 2016 06:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LAq3LudMXQzuPzOQXUkNbA5aafcMso/lDARUqRPjurc=; b=Tz1FD35Oc2ubd/4AJzqVKkE7e93VG27gnmJf705qO/pBAbr22uID85+PQvvmiQHRpd C85GN06ZpXvkHBzv7AqoHbuFAPo1wkSINtUcpYW+m0fSi7pGCRCHjHgc9QYtc9fsWotu vDUqMV6lf9IGU1/3JQnn/7ex3Fg77JzRj35coufYBZipY8ljkY2nx81MyPornu7uP+LF zqvYlSJI7JBZpO4DGF93WIpB5jyYnbeUjtv7auwsGMz8J5/YuFCnHWEbXE6GYzNj8RM1 O6Nyk/60pp0dN8rlVAUMtn+g4vcQQ3rLDAODrRptNUSqiegJ0FWFM7OM30COL0KVIkut kmaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LAq3LudMXQzuPzOQXUkNbA5aafcMso/lDARUqRPjurc=; b=Tod+LTUjoa9mFF1AlYHm7U/QRYPgKz21SJZV7DqL3OntVBxW40XpzPUZsrjbZF/IJD gqYaajYbJYaX0LpCsxUz4e5jZ0hOxhM459JkoBNlSBHH+tGpVraMXhnxBljG2Hnaq2wk CWWSEK8WB/wSmnLMGz7o0N0DgAHtiA93pQRzap/r9HxL0Z2hOPOB8g8i4METLQDDE07S 3RhUraQ6ov0GIglj7o828bUVKZZNU8OEgcSyTL9zSFz2e0I2+BGJfHzJF57J7BJuVleY 9Inrz14l7XugPMTfMcYGGgW1MPx3N3mrBN41FrBMFH8G9YS17VMafLIyNonhVITZc11g FGNA== X-Gm-Message-State: ABUngvep7GqelBM8zgpzm5kVw9SiR6tHfQQH5WbQ75ymhGs2s2PdAccdtxR9S6/RuSnpaO4BkVEpx0VzBbUErw== X-Received: by 10.28.73.214 with SMTP id w205mr3393648wma.86.1477401772780; Tue, 25 Oct 2016 06:22:52 -0700 (PDT) In-Reply-To: <83twckekqq.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::22e 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:208758 Archived-At: --001a114b30f8db8d76053fb0677b Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Mo., 10. Okt. 2016 um 09:17 Uhr: > > > 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. > > But we don't even know whether these problems are relevant to what Tom > implemented in the concurrency branch. > We have lots of experience from other programming languages. Emacs isn't that different (Elisp is mostly Python with a strange syntax), so we can transfer experience to Emacs. Specifically, we don't have to reinvent everything from scratch. There are a couple of high-level concurrency models (STM, CSP) that are widely used in practice already. Out of curiosity I've implemented Plan9/Go-style CSP based on libtask (without OS threads) in Emacs with minimal changes, and most things seem to work just fine. > > We've gone a long way since this issue was first brought up. We've > changed our sources in significant ways to support concurrency: all > those BVAR and KVAR macros that are all around the C sources were > introduced for that very purpose. Likewise, the globals.h header > file, and the fact that each variable exposed to Lisp is a member of > some C struct -- all this was for supporting concurrency. The code > for this is written, debugged, and is only a little ways from being > ready for prime time. We still have tons of global mutable state, e.g. the buffer list. Traditional OS-level multithreading is impossible with that amount of global state. On the other hand, non-parallel concurrency doesn't care about global state (which can just be swapped out) at all. --001a114b30f8db8d76053fb0677b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Mo., 10. Okt. 2016 um 09:17=C2=A0Uhr:

> The reason I love Haskell for its STM concurrency (software transactio= nal
> memory) is that it makes certain classes of problems impossible to exp= ress. 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 opera= tions
> that should be atomic aren't. I'd rather have a single-threade= d Emacs for a
> quite a while longer before inviting these sorts problems into our liv= es.

But we don't even know whether these problems are relevant to what Tom<= br class=3D"gmail_msg"> implemented in the concurrency branch.
=

We have lots of experience from other programming langu= ages. Emacs isn't that different (Elisp is mostly Python with a strange= syntax), so we can transfer experience to Emacs. Specifically, we don'= t have to reinvent everything from scratch. There are a couple of high-leve= l concurrency models (STM, CSP) that are widely used in practice already.
Out of curiosity I've implemented Plan9/Go-style CSP based on = libtask (without OS threads) in Emacs with minimal changes, and most things= seem to work just fine.
=C2=A0

We've gone a long way since this issue was first brought up.=C2=A0 We&#= 39;ve
changed our sources in significant ways to support concurrency: all
those BVAR and KVAR macros that are all around the C sources were
introduced for that very purpose.=C2=A0 Likewise, the globals.h header
file, and the fact that each variable exposed to Lisp is a member of
some C struct -- all this was for supporting concurrency.=C2=A0 The code for this is written, debugged, and is only a little ways from being
ready for prime time.

We still have tons of= global mutable state, e.g. the buffer list. Traditional OS-level multithre= ading is impossible with that amount of global state.
On the othe= r hand, non-parallel concurrency doesn't care about global state (which= can just be swapped out) at all.
--001a114b30f8db8d76053fb0677b--