From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Concurrency, again Date: Wed, 12 Oct 2016 20:17:26 +0300 Message-ID: <83mvi9a3mh.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476292720 18866 195.159.176.226 (12 Oct 2016 17:18:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Oct 2016 17:18:40 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 12 19:18:36 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 1buNAj-0003sf-DR for ged-emacs-devel@m.gmane.org; Wed, 12 Oct 2016 19:18:29 +0200 Original-Received: from localhost ([::1]:34850 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buNAh-0005RD-SS for ged-emacs-devel@m.gmane.org; Wed, 12 Oct 2016 13:18:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54875) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buNA0-0005Or-HG for emacs-devel@gnu.org; Wed, 12 Oct 2016 13:17:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buN9x-0007wd-Ak for emacs-devel@gnu.org; Wed, 12 Oct 2016 13:17:44 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buN9x-0007wB-7Q; Wed, 12 Oct 2016 13:17:41 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3247 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buN9u-0003ni-RZ; Wed, 12 Oct 2016 13:17:39 -0400 In-reply-to: (message from John Wiegley on Wed, 12 Oct 2016 09:42:01 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:208180 Archived-At: > From: John Wiegley > Date: Wed, 12 Oct 2016 09:42:01 -0700 > Cc: emacs-devel@gnu.org > > Look at what happened with curly quotes: seemingly simple, it got merged into > master "as an experiment". Then witness how many little issues kept popping up > everywhere, how much debate on this list, all for something I'm sure many > thought was totally benign. Now we're talking about doing the same with > something as open-ended as threading? Introduction of a significant new feature such as concurrency should be expected to destabilize Emacs. It is not a minor feature like quoting. OTOH, quotes are pervasive in Emacs; most of the issues we had as fallout were due to that pervasiveness, something that was not appreciated at first. By contrast, concurrency is NOT pervasive: it only happens if a Lisp application requests that explicitly. As long as we don't convert standard Emacs features to use concurrency, it will not happen in day-to-day operations. We've had a much tougher decision when bidirectional editing was added to Emacs. Unlike concurrency, bidi affects every aspect of Emacs, because it changed how the display engine works in fundamental ways. Stefan and Chong, who made that decision, had all the reasons to get their feet cold, but they made that decision anyway. I think the risk was much higher then than it is now. Given the level of expertise Tom Tromey has in both Emacs and concurrency, I see no reason to be afraid now that something terrible will happen that couldn't be fixed as part of the normal development process. And if worse comes to worst, and we discover at some point that concurrency gives us too much trouble for its worth, we can always remove it from Emacs. Once again, the concurrency branch is not yet ready for a merge. Before it is ready, someone should fix the few remaining issues, and perhaps try using it in a real-life application (which will most probably expose some more issues). Unless someone volunteers to do that, there's no "danger" the concurrency branch will ever be merged. > What could be done to gain experience, as Eli suggests, is maintain a parallel > fork, the way Firefox is doing with their e10s support. That is, build a > version of Emacs with threading enabled and, for a couple of years, release it > in parallel with the main Emacs. Then pick one candidate package, say Gnus, > and have it demonstrate that threading makes everyone's life better, without > making things worse for the rest of us. I don't think this is practical, what with the resources we have. > If that's too much work to do, my guess is that it's too much work to maintain > threading with the contributors we now have. My prediction is that it will > increase our workload, since a new class of bugs will appear that are much > harder to reproduce and reason about than the sorts of issues we face now. I urge you to have a look at the sources on the concurrency branch. There's no threading, in the usual sense of that word: at any given time, only a single thread is running. It's not at all what you seem to be imagining. Think about idle timers that run without your having to do anything to start them: that's what we have there, in a nutshell, plus a few niceties.