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: Sun, 16 Oct 2016 09:40:09 +0300 Message-ID: <83a8e423w6.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> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476600043 32301 195.159.176.226 (16 Oct 2016 06:40:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 16 Oct 2016 06:40:43 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 16 08:40:33 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 1bvf7Y-0006xL-R7 for ged-emacs-devel@m.gmane.org; Sun, 16 Oct 2016 08:40:33 +0200 Original-Received: from localhost ([::1]:55256 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvf7Z-000835-W5 for ged-emacs-devel@m.gmane.org; Sun, 16 Oct 2016 02:40:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37822) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvf7S-000830-EB for emacs-devel@gnu.org; Sun, 16 Oct 2016 02:40:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bvf7N-0001RC-Vn for emacs-devel@gnu.org; Sun, 16 Oct 2016 02:40:26 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bvf7N-0001R6-Sg; Sun, 16 Oct 2016 02:40:21 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1838 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bvf7D-0008SK-Jm; Sun, 16 Oct 2016 02:40:12 -0400 In-reply-to: (message from Richard Stallman on Sat, 15 Oct 2016 18:03:15 -0400) 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:208319 Archived-At: > From: Richard Stallman > CC: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > Date: Sat, 15 Oct 2016 18:03:15 -0400 > > > That's what the code on the "concurrency" branch of the Emacs > > repository does -- except that (1) it doesn't allow you to create > > special asynchronous programs at all, and (2) it is capable of > > switching to another ordinary Lisp program when the current one is > > waiting for something (e.g., keyboard input or subprocess output), or > > explicitly yields to another. > > (2) is a source of possible conflicts between various programs; I > suspect that lots of bugs could result. I believe Tom Tromey, who wrote the code, took precautions so that such bugs won't happen "by design". Some design principles and limitations towards this end are: . thread switching happens either when Emacs is waiting for input, or by explicit request of a thread to yield, or when a thread blocks because it waits for a mutex or to join another thread . global variables are shared between all threads, but local variable let-bindings are specific to the thread that made them . each thread has its own current buffer and its own match data . by default, a process is locked to the thread that created it, which means output from the process can only be accepted by that thread; however, a Lisp program can specify to which thread a process is locked, or unlock the process, in which case any thread can accept its output. In any case, once some thread starts waiting for output of a process, the process becomes temporarily locked to that thread, so only that thread will eventually receive the output, unless it yields. If a thread exits, all its processes are unlocked. > Are such bugs why the "concurrency" branch is not ready? We don't really know, because the branch was never seriously used. > To limit concurrency to specially designated programs > might make it easier to avoid those problems. Those programs > could conceivably be written following certain special rules > that avoid the bugs. That's what the branch does: if a Lisp program doesn't create any threads, it will run normally, as in today's Emacs, using a single main thread.