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: Very interesting analysis of "the state of Emacs" Date: Fri, 02 May 2008 11:36:20 -0400 Message-ID: References: <481693C3.70901@emf.net> <4816CDB6.6000006@pajato.com> <4817D79F.8040508@gmail.com> <874p9jhsa7.fsf@localhorst.mine.nu> <87bq3qodp4.fsf@bar.jrock.us> <87od7qikyc.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1209742615 16065 80.91.229.12 (2 May 2008 15:36:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 May 2008 15:36:55 +0000 (UTC) Cc: Jonathan Rockway , Emacs Devel To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 02 17:37:30 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 1JrxK2-0000BP-Uy for ged-emacs-devel@m.gmane.org; Fri, 02 May 2008 17:37:19 +0200 Original-Received: from localhost ([127.0.0.1]:59354 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JrxJL-00036m-GZ for ged-emacs-devel@m.gmane.org; Fri, 02 May 2008 11:36:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JrxJG-00036D-QF for emacs-devel@gnu.org; Fri, 02 May 2008 11:36:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JrxJF-00035a-0n for emacs-devel@gnu.org; Fri, 02 May 2008 11:36:30 -0400 Original-Received: from [199.232.76.173] (port=47148 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JrxJE-00035T-KL for emacs-devel@gnu.org; Fri, 02 May 2008 11:36:28 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182] helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JrxJ8-0003Ch-MU; Fri, 02 May 2008 11:36:22 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtICAL7RGkjO+JghdGdsb2JhbACBU5ARASeZXA X-IronPort-AV: E=Sophos;i="4.27,427,1204520400"; d="scan'208";a="19817726" Original-Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 02 May 2008 11:36:20 -0400 Original-Received: from pastel.home ([206.248.152.33]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id IUM43720; Fri, 02 May 2008 11:36:20 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 10ECD7F63; Fri, 2 May 2008 11:36:20 -0400 (EDT) In-Reply-To: <87od7qikyc.fsf@catnip.gol.com> (Miles Bader's message of "Thu, 01 May 2008 15:42:51 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: 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:96339 Archived-At: >> The issue is when we start putting global variables into the mix: > ... >> Anyway, hopefully someone has some ideas on what to do here. I admit I >> haven't looked at how sxemacs handles this yet. Maybe we can just deal >> with locks? At least in that case my IMAP mail could download while I >> am typing in another buffer :) > If the multi-threading were cooperative (as rms suggested), then such > problems would obviously be a bit easier to manage -- you can basically > just say "no context switches except at well defined points", and define > these "points" to be (1) user interaction/recursive edits [where the > user can do something to "screw up the state" even today], or (2) > explicit calls to yield. W.r.t to concurrency, I think we need to think about how to introduce it into Emacs, indeed. The reason why I think so is because in order to evolve Emacs needs to eat up more CPU. You may think Emacs is not CPU bound, but it's only the case because it only uses what is available. Try to run Emacs-22 on a 486 to get an idea of what I mean. Single-thread CPU power is very unlikely to increase significantly in the future, so if we want to get access to the additional CPU power we'll need concurrency. Now we already have concurrency, in the form of start-process. `flyparse' and `flymake' do just that. And maybe that's good enough. But I expect that closer integration of additional threads will be needed/useful at some point. Other than separate processes, we can add threads without affecting Elisp, by using separate threads for the GUI and for the redisplay. Even the redisplay could be parallel by using separate threads per frame/window. As for adding concurrency to Elisp, the core difficulty will be the heap of code that assumes concurrency doesn't exist, as well as the interaction between buffer-local and let-bound variables. But indeed, I think a good first step is to add coroutines. This should not be terribly difficult to do (especially since it's OK for it to break code as long as it's only broken when you use `yield'). Patches welcome. > However I think there are potentially additional problems with dynamic > scope: remember, elisp uses shallow scoping, where binding a variable > is basically "save old value, and set global". For normal variables, > this could be replaced by deep-binding, which is more multi-threading > friendly (my "lexbind" branch already uses deep-binding in the > interpreter), but afaik, the use of shallow-binding in elisp is kind of > intertwined with the implementation of buffer-local variables and the > like, and I'm not so sure how easy it would be to handle such things > with a new deep-binding implementation. The way I see it, multithreading within a buffer is a problem we can ignore for the next 20 years. So let-binding a buffer-local var can be handled via shallow-binding (whereas let-binding of global variables needs to use deep binding). So the only difficulty is to deal with variables which are not make-variable-buffer-local but only make-local-variable where we need to make sure we can always unequivocally know whether to use deep or shallow binding. Stefan