From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: multi-threaded Emacs Date: Sat, 06 Dec 2008 17:41:20 -0500 Message-ID: References: <87abbiody1.fsf@master.homenet> <877i6l5d8s.fsf@master.homenet> <874p1npvtj.fsf@master.homenet> <87ej0qci8g.fsf@master.homenet> <87y6yxm7xr.fsf@master.homenet> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1228603299 16074 80.91.229.12 (6 Dec 2008 22:41:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Dec 2008 22:41:39 +0000 (UTC) Cc: gscrivano@gnu.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 06 23:42:42 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L95rF-00056g-Gr for ged-emacs-devel@m.gmane.org; Sat, 06 Dec 2008 23:42:41 +0100 Original-Received: from localhost ([127.0.0.1]:43673 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L95q4-0008Qt-RQ for ged-emacs-devel@m.gmane.org; Sat, 06 Dec 2008 17:41:28 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L95q1-0008Qg-Fx for emacs-devel@gnu.org; Sat, 06 Dec 2008 17:41:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L95q0-0008QQ-R4 for emacs-devel@gnu.org; Sat, 06 Dec 2008 17:41:25 -0500 Original-Received: from [199.232.76.173] (port=35945 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L95q0-0008QL-L0 for emacs-devel@gnu.org; Sat, 06 Dec 2008 17:41:24 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:40096) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L95px-0000U6-Le; Sat, 06 Dec 2008 17:41:21 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAIeOOknO+Jkl/2dsb2JhbACBbco8gwWBJg X-IronPort-AV: E=Sophos;i="4.33,726,1220241600"; d="scan'208";a="30745412" Original-Received: from 206-248-153-37.dsl.teksavvy.com (HELO pastel.home) ([206.248.153.37]) by ironport2-out.teksavvy.com with ESMTP; 06 Dec 2008 17:41:20 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 84A4F8219; Sat, 6 Dec 2008 17:41:20 -0500 (EST) In-Reply-To: (Richard M. Stallman's message of "Sat, 06 Dec 2008 14:25:57 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:106637 Archived-At: > It will be safe in the sense that it won't cause a crash. But it will > mess up Elisp's semantics. Consider: > (dotimes (i 1000) (toto)) > if you run this code twice in separate threads and allow context > switches at QUIT, then you'll basically be doing "preemptive > concurrency" seen from Elisp's point of view. Among other things, the > two threads will be fighting over the value of `i'. > Each thread should have its own local bindings. To do this > requires swapping bindings in and out of the specpdls > when switching threads. It is not hard. > This makes thread switches slower, and that makes it desirable > to do them less often. It might be an acceptable temporary solution, but in the long term we will want to allow true parallelism, so such trickery will not be an option. Whether it'll be a valuable intermediate point or not, I cannot say. My gut feeling is that we'd better work on a solution that will work in the longer run. Currently my guess is that generalizing the existing buffer-local/frame-local/terminal-local machinery to include thread-local is going to work well, with fairly limited changes. Stefan