From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Concurrency, again Date: Thu, 13 Oct 2016 14:14:55 -0400 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> <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476382542 10925 195.159.176.226 (13 Oct 2016 18:15:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Oct 2016 18:15:42 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 13 20:15:38 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 1bukXB-0008RC-Dv for ged-emacs-devel@m.gmane.org; Thu, 13 Oct 2016 20:15:13 +0200 Original-Received: from localhost ([::1]:42410 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bukXA-00030Z-5B for ged-emacs-devel@m.gmane.org; Thu, 13 Oct 2016 14:15:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bukX1-0002yr-4a for emacs-devel@gnu.org; Thu, 13 Oct 2016 14:15:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bukWw-0000wZ-36 for emacs-devel@gnu.org; Thu, 13 Oct 2016 14:15:03 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:39243) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bukWv-0000wG-TS for emacs-devel@gnu.org; Thu, 13 Oct 2016 14:14:58 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id u9DIEWTP020891; Thu, 13 Oct 2016 14:14:33 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 93498601DC; Thu, 13 Oct 2016 14:14:55 -0400 (EDT) In-Reply-To: (John Wiegley's message of "Thu, 13 Oct 2016 10:25:26 -0700") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV5826=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5826> : inlines <5345> : streams <1715861> : uri <2307017> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:208212 Archived-At: > I can't think of too many cases where existing Emacs Lisp would immediately > benefit from being massively parallel, either. I think the benefit only exists if we want to increasing the functionality along with the available compute power. AFAIK single-thread performance has reached a plateau about ten years ago and there's no sign of its end, and Emacs is "stuck" in this plateau. Luckily for us, Emacs is far from the only one: very few programs nowadays know how to take advantage of the extra compute power. But I see no way to make Emacs take much advantage of parallelism, other than in completely separate tasks written in other languages (e.g. a separate executable scanning all a project's files in parallel). All I was pointing out is that this discussion is about concurrency and not parallelism. > answer the main question -- in my mind, the only question when it comes to > whether we should consider including this type of support: Will it solve the > annoyance people have of Emacs blocking when they ask it to do certain things? Indeed. > I just want to make sure we're not try to solve the technical problem just > because it's solvable; we should only solve it if it's a real problem that is > getting in people's way, or is stopping us from doing the Next Cool Thing. AFAIK the issue is fairly simple: writing async code (with process filters/sentinels) in Elisp is rather painful, which is why we have those blocking situations (which could all be fixed by a "bit" of rewriting). So don't think of it as "how can we avoid those breaks" but rather "how can we make it easier for the programmer to write non-blocking code". I'm sure it'll break code. But I think it's worth a try, if only to convince ourselves that Elisp will never ever move away from the single-thread world. Stefan