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: Wed, 12 Oct 2016 15:43:12 -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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1476301452 2049 195.159.176.226 (12 Oct 2016 19:44:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Oct 2016 19:44:12 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 12 21:44:08 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 1buPRP-0006M5-94 for ged-emacs-devel@m.gmane.org; Wed, 12 Oct 2016 21:43:51 +0200 Original-Received: from localhost ([::1]:35417 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buPRN-0008I1-Sx for ged-emacs-devel@m.gmane.org; Wed, 12 Oct 2016 15:43:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34428) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buPQs-0008Ht-6S for emacs-devel@gnu.org; Wed, 12 Oct 2016 15:43:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buPQo-00054D-Vj for emacs-devel@gnu.org; Wed, 12 Oct 2016 15:43:18 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:48605) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buPQo-00053Q-P3; Wed, 12 Oct 2016 15:43:14 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id u9CJb5kq021358; Wed, 12 Oct 2016 15:37:06 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 1C58766204; Wed, 12 Oct 2016 15:43:12 -0400 (EDT) In-Reply-To: (John Wiegley's message of "Wed, 12 Oct 2016 11:01:35 -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, RV5825=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5825> : inlines <5341> : streams <1715387> : uri <2306409> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:208184 Archived-At: >> 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. > More akin to green threading then? Right. It does introduce the possibility to have new interleavings, so new bugs, but 99% of the bugs it uncovers should be reproducible (at least in theory; tho maybe only in convoluted circumstances) in the non-concurrent branch as well. > It's interesting to note how many people agree with caution, or don't claim to > need threading, vs. those calling for its inclusion. I know many users who > don't want Emacs locking up on them. This is the problem that needs solving. > Is threading in Emacs Lisp the answer? I still don't know. I think there are many different needs/desires related to "concurrency". A typical one (for me anyway) is: - I want to use Gnus, but I want to be able to edit files while Gnus consults the IMAP server to see if there are new messages, or while Gnus is waiting for the damn NNTP server to answer. Currently I solve this problem by running Gnus in a separate Emacs session (i.e. I basically always have 2 Emacs processes). I lived with it for the last 20 years, so it's not that bad, but it's inconvenient. The concurrency branch should be able to solve this problem. We could probably solve this problem also using a cps-translation like the one in generator.el, to take the synchronous code using accept-process-output, and turn it into code which runs asynchronously, from the process filters&sentinels. It's likely to be somewhat brittle, tho. - I want semantic-mode to scan my buffers in the background and to scan several buffers at the same time, to make use of my 8 cores. The concurrency branch doesn't really try to solve this problem. I'm not sure what's the best way to solve this problem, and I don't even know what would be a "simple" way to solve this problem. -- Stefan