From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: Multithreading, again and again Date: Thu, 20 Oct 2011 11:07:33 -0600 Message-ID: References: <4E82C377.4040007@yandex.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1319130471 18145 80.91.229.12 (20 Oct 2011 17:07:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 20 Oct 2011 17:07:51 +0000 (UTC) Cc: Dmitry Antipov , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 20 19:07:45 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RGw5n-0004Gd-MT for ged-emacs-devel@m.gmane.org; Thu, 20 Oct 2011 19:07:43 +0200 Original-Received: from localhost ([::1]:53454 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGw5m-00052H-Ps for ged-emacs-devel@m.gmane.org; Thu, 20 Oct 2011 13:07:42 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:47590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGw5j-00051w-MR for emacs-devel@gnu.org; Thu, 20 Oct 2011 13:07:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RGw5i-0005TL-C7 for emacs-devel@gnu.org; Thu, 20 Oct 2011 13:07:39 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:3877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGw5i-0005TA-4L for emacs-devel@gnu.org; Thu, 20 Oct 2011 13:07:38 -0400 Original-Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9KH7aa7017375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Oct 2011 13:07:36 -0400 Original-Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p9KH7ZK5009720; Thu, 20 Oct 2011 13:07:35 -0400 Original-Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p9KH7X8E015044; Thu, 20 Oct 2011 13:07:34 -0400 X-Attribution: Tom In-Reply-To: (Stefan Monnier's message of "Wed, 19 Oct 2011 17:33:02 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 209.132.183.28 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:145367 Archived-At: >>>>> "Stefan" == Stefan Monnier writes: Tom> I think it is doable, given the context-switching constraints I Tom> mentioned earlier. Stefan> Yes a "simple" switch-on-yield should be sufficient (i.e. the old Stefan> concurrency branch should be able to handle it), but that still means Stefan> that solving such a problem requires handling interaction between the Stefan> various kinds of Elisp variable bindings (thread-local, buffer-local, Stefan> ...). Yes. Tom> The long-term thing that would be cool is context-switching during QUIT. Stefan> I'm not sure it would be significantly easier than true concurrency. Tom> I don't think unconstrained context-switching is possible without some Tom> drastic changes to the implementation. Stefan> Why do you think so? If you want all threads to run freely, then you have to make the Emacs C code atomic with respect to any globally-visible change. I just have no confidence that it is this way right now. Tom> My plan was to follow the Bordeaux threads API, more or less. Stefan> I'm afraid that using locks is not going to work well for Elisp. Stefan> I have much higher expectations for approaches based on yield Stefan> (i.e. approaches which are inherently safe(r), with the main Stefan> risk being lack of concurrency rather than race-conditions and Stefan> corruption). Tom> Can you expand on this? Stefan> I'm not sure what kind of expansion you'd like to see: if you forget Stefan> a lock you can get data corruption, whereas if you forget a yield you Stefan> may just block a bit more often than desired (but still less often than Stefan> in Emacs-23). Ok, I thought by "yield" you were perhaps thinking of some kind of co-routine-like model or something like that. But if I read this correctly you mean just a thread yield operation? (Called "thread-yield" on the concurrency-2 branch...) I think cooperativeness doesn't really eliminate the need for locks, especially because I plan to allow context switches at I/O (and some other blocking operations, like mutex acquisition). Of course, the situation is really a bit like process filters. Probably a lot of actually existing Emacs Lisp code will run fine with multiple threads, even without any locking whatsoever. That will remain true for some time: either multiple threads will be due to multiple keyboards (in which case users probably won't be surprised by odd behavior they caused themselves) or multiple threads will be from new code using the new feature, which generally won't be written to randomly stomp all over everything. Tom