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: Concurrency, again Date: Sat, 15 Oct 2016 17:38:36 -0700 Message-ID: References: <87wq97i78i.fsf@earlgrey.lan> <9D64B8EA-DB52-413D-AE6A-264416C391F3@iotcl.com> <83int1g0s5.fsf@gnu.org> <83twckekqq.fsf@gnu.org> <83mvi9a3mh.fsf@gnu.org> <20161012165911.58437154@jabberwock.cb.piermont.com> <20161012173314.799d1dc5@jabberwock.cb.piermont.com> <8360owaj2s.fsf@gnu.org> <20161013092701.77461800@jabberwock.cb.piermont.com> <83r37i2mdx.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476578393 18005 195.159.176.226 (16 Oct 2016 00:39:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 16 Oct 2016 00:39:53 +0000 (UTC) User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (darwin) Cc: Eli Zaretskii , monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 16 02:39:43 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 1bvZUC-0002F5-Jh for ged-emacs-devel@m.gmane.org; Sun, 16 Oct 2016 02:39:32 +0200 Original-Received: from localhost ([::1]:54536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvZUE-0006nj-C1 for ged-emacs-devel@m.gmane.org; Sat, 15 Oct 2016 20:39:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvZTd-0006nZ-85 for emacs-devel@gnu.org; Sat, 15 Oct 2016 20:38:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bvZTZ-0007QL-18 for emacs-devel@gnu.org; Sat, 15 Oct 2016 20:38:57 -0400 Original-Received: from mail-pf0-x22d.google.com ([2607:f8b0:400e:c00::22d]:34313) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bvZTT-0007O2-I1; Sat, 15 Oct 2016 20:38:47 -0400 Original-Received: by mail-pf0-x22d.google.com with SMTP id r16so41150640pfg.1; Sat, 15 Oct 2016 17:38:47 -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=QHJfjTrwX3Fe0RrJgQlb8OyGew5Ep7yMWXtzoPToLGU=; b=pt/q//1Tkuneh/vvI/VQK7d4U5ctDLM5LBpqRn4YwXx6lVV1FK1HTGvG9xD1hmAOI0 UCKn1Vl6A+2uRWxznfC8QIg1P6ga1ft+Xe9p2BETiuFshzCn7s3aBnh/t1BjO5UVXUwN UuUWkTJT9/sxi4UHtwV4bB/sTesn1X7pyX8r5GgoF/zd+UPzqUT2D6fqw5AJbeCpNqBS 7z7/CJ0QZNOUsWYhRirNo+MZpXUW/ciNvP/i49sfEY+J7X9eKJYFTmyWxwf6Zni1Rtor wRzTBadvieEJyZRTNIZnwB1vyct/upXo1n4oDGXcrkR2IsiDU0HSKIgf16rDtb0A0KEX kOnA== 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=QHJfjTrwX3Fe0RrJgQlb8OyGew5Ep7yMWXtzoPToLGU=; b=lfv7mrvpMjZrQky+1ffIXAQLzfi9/ipzytMhBbbjZdWOomKOVhHfbm1TxUc6KTA/+9 qmQKsm2SN5unq3w5ffyNcek/NJXd6ay0VaXysW/jQmA2FQegBYc6TJdmTufDFENp6ciR DInH+6kph+IM8vqWNYux9DxRAXLB8dmbOn2SW+8S3zj8uZtu5H9JEaW2o5U0yLw4nG9a sMtCw69kib91NH3v6xJyZfBTMW8eS899PhNdc7bzWjYvJTBGWMVTjNeoA3PiNeqbYHJH Tp8viMZaGDNQkiVPGvSljbm4aQkw6snwW+wBJRLnn5YwxnjXFxRwZkin8s/c0ErcqQ1d jlHQ== X-Gm-Message-State: AA6/9Rmw9P6yuVZXrxow7Z6Ys1SQGYa6rYfCySEFqPbxyuTEJAVA8xCMD7X8p4QSFG7O0Q== X-Received: by 10.98.0.198 with SMTP id 189mr23543678pfa.75.1476578326067; Sat, 15 Oct 2016 17:38:46 -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 m20sm37491871pfk.96.2016.10.15.17.38.43 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 15 Oct 2016 17:38:43 -0700 (PDT) X-Google-Original-From: "John Wiegley" Original-Received: by Vulcan.local (Postfix, from userid 501) id 6731F302CA0B; Sat, 15 Oct 2016 17:38:43 -0700 (PDT) In-Reply-To: (Richard Stallman's message of "Sat, 15 Oct 2016 18:03:15 -0400") Mail-Followup-To: Richard Stallman , Eli Zaretskii , monnier@IRO.UMontreal.CA, 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:c00::22d 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:208315 Archived-At: >>>>> "RS" == Richard Stallman writes: RS> (2) is a source of possible conflicts between various programs; I suspect RS> that lots of bugs could result. Are such bugs why the "concurrency" branch RS> is not ready? RS> To limit concurrency to specially designated programs might make it easier RS> to avoid those problems. Those programs could conceivably be written RS> following certain special rules that avoid the bugs. I'd like to note that the danger of such bugs really depends on how heavily a given software package plays tricks with mutexes and yields. For counter-example: Eshell today contains a function called `eshell-do-eval', whose sole purpose is to evaluate a Lisp form up to a point where it would otherwise block; save the current execution stack manually as a continuation lambda in a global; then resume execution where it left off the next time evaluation is attempted. This code -- which is by far the most complex aspect of Eshell -- would simply disappear once `thread-yield` became available, since that's exactly what Eshell needs to do: yield execution until a condition is met, provided the user isn't busily engaged doing something else. So, for some use cases, threads as they've been proposed will simplify code and reduce bugs, not make things worse. It depends on *how* it is used, what damage it will do. I suppose the question then is: How much rope are we giving new programmers to hang themselves with? There have been other suggestions made to offer a better interface on top of the threading primitives -- based on the actor model, or message passing, or transactions, or futures, etc. -- such that none of the failure modes we fear are possible through such an interface. This would restrict what users can do, but might not restrict them so much that they can't achieve what is needed to make Emacs less blocking. So, even if we merged the concurrency branch today, this doesn't immediately invite the hellhounds. It's just an implementation strategy, after all, for allowing interleaved evaluation. I'm sure we can devise bulletproof ways to make use of that functionality to achieve our end goal. If not, we revert. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2