From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Perry E. Metzger" Newsgroups: gmane.emacs.devel Subject: Re: Concurrency, again Date: Wed, 12 Oct 2016 17:33:14 -0400 Message-ID: <20161012173314.799d1dc5@jabberwock.cb.piermont.com> 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> <83mvi9a3mh.fsf@gnu.org> <20161012165911.58437154@jabberwock.cb.piermont.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1476308019 19757 195.159.176.226 (12 Oct 2016 21:33:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Oct 2016 21:33:39 +0000 (UTC) Cc: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: =?ISO-8859-1?Q?S=F8ren_Pilg=E5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 12 23:33:35 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 1buR9X-0004FS-Jn for ged-emacs-devel@m.gmane.org; Wed, 12 Oct 2016 23:33:31 +0200 Original-Received: from localhost ([::1]:36015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buR9W-0003uk-9C for ged-emacs-devel@m.gmane.org; Wed, 12 Oct 2016 17:33:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buR9N-0003tW-Jl for emacs-devel@gnu.org; Wed, 12 Oct 2016 17:33:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buR9L-0004fm-Tm for emacs-devel@gnu.org; Wed, 12 Oct 2016 17:33:20 -0400 Original-Received: from hacklheber.piermont.com ([166.84.7.14]:38852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buR9I-0004ak-10; Wed, 12 Oct 2016 17:33:16 -0400 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 4979F7C3; Wed, 12 Oct 2016 17:33:15 -0400 (EDT) Original-Received: from jabberwock.cb.piermont.com (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with ESMTP id 121802DE01E; Wed, 12 Oct 2016 17:33:14 -0400 (EDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 166.84.7.14 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:208191 Archived-At: On Wed, 12 Oct 2016 23:20:21 +0200 S__ren Pilg__rd wrote: > > One possibility: move to a multiple processes paradigm where each > > buffer has an associated process, and global variable values are > > propagated via message passing to a master process. Think Hoare's > > CSP or Go or Erlang for precedents, though perhaps with more > > sugaring to make it easy for Emacs users to not think much about > > global state. > > > > This sort of model might be especially important if Emacs starts > > being used as a serious web browser by lots of its community, > > given how much CPU modern browsers can eat. > > > > The thing is all current code expects to be able to access any > buffer they like without interferrence from other code. > So to make this new model work we would need to support both > paradigms. If any "old-style" code started execution, by being > called by a function or from a timer, then the entire world would > have to halt so the old-style code could execute with its > assumption of sequential access. Well, the code expects to *access* buffers, but it doesn't expect to interact with other executing code. So for "new" code, you would need to allow code to be able to get to a buffer's contents by some protocol (possibly even transparent to that process), but it need not (necessarily) have low level shared data structures the way a pthreads-like model allows. I have to admit I haven't thought through all the implications here, that was an impulse post on my part and I somewhat regret making it without thinking longer. OTOH, I've become fairly convinced over time that what is preferable are paradigms where there is zero shared low level state between executing processes. You just lose all your hair otherwise yanking it out when you hit bugs. That said, given the fact that Emacs concurrency would have to evolve from the current way of doing things, it might be completely infeasible to implement such a paradigm. > And then each "new-style" code currently executing would have to > "finish" its execution and somehow mark that now its buffer and > bufferlocal variables are in a safe state for the old-style code to > execute. > When all current new-style code is marked "safe" then the old-style > code can execute and when done emacs can continue execution of all > the new-style code. > Does this make sense? That's certainly one possible way of doing things that would allow migration to a new paradigm without breaking old code. Concurrency is a giant tarpit of subtleties. :( Perry -- Perry E. Metzger perry@piermont.com