From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Very interesting analysis of "the state of Emacs" Date: Thu, 01 May 2008 15:42:51 +0900 Message-ID: <87od7qikyc.fsf@catnip.gol.com> References: <481693C3.70901@emf.net> <4816CDB6.6000006@pajato.com> <4817D79F.8040508@gmail.com> <874p9jhsa7.fsf@localhorst.mine.nu> <87bq3qodp4.fsf@bar.jrock.us> Reply-To: Miles Bader NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1209624198 25092 80.91.229.12 (1 May 2008 06:43:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 May 2008 06:43:18 +0000 (UTC) Cc: Emacs Devel To: Jonathan Rockway Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 01 08:43:54 2008 connect(): Connection refused 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 1JrSWI-0008FF-7z for ged-emacs-devel@m.gmane.org; Thu, 01 May 2008 08:43:54 +0200 Original-Received: from localhost ([127.0.0.1]:52180 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JrSVb-0000Ih-Aq for ged-emacs-devel@m.gmane.org; Thu, 01 May 2008 02:43:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JrSVW-0000IS-ST for emacs-devel@gnu.org; Thu, 01 May 2008 02:43:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JrSVT-0000IF-KC for emacs-devel@gnu.org; Thu, 01 May 2008 02:43:05 -0400 Original-Received: from [199.232.76.173] (port=45545 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JrSVT-0000IC-FR for emacs-devel@gnu.org; Thu, 01 May 2008 02:43:03 -0400 Original-Received: from smtp11.dentaku.gol.com ([203.216.5.73]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JrSVO-0006fZ-H3; Thu, 01 May 2008 02:42:58 -0400 Original-Received: from 203-216-99-062.dsl.gol.ne.jp ([203.216.99.62] helo=catnip.gol.com) by smtp11.dentaku.gol.com with esmtpa (Dentaku) id 1JrSVL-0005la-Fp; Thu, 01 May 2008 15:42:55 +0900 Original-Received: by catnip.gol.com (Postfix, from userid 1000) id 0F1472F4D; Thu, 1 May 2008 15:42:51 +0900 (JST) System-Type: i686-pc-linux-gnu In-Reply-To: <87bq3qodp4.fsf@bar.jrock.us> (Jonathan Rockway's message of "Wed, 30 Apr 2008 23:23:03 -0500") Original-Lines: 37 X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) 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:96266 Archived-At: Jonathan Rockway writes: > 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. Even with such a restrictive system, I think it's _much_ easier to make a potentially slow bit of elisp code (gnus or whatever) multi-threadable by sticking in (yield) calls at strategic places, and of course you'd make sure that these places were chosen so that any global state depended on after the yield returns is restricted to places that are very unlikely to be modified (e.g., if gnus is reading from nntp, for instance, it could keep all state in its own scratch buffers). 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. -Miles -- Admiration, n. Our polite recognition of another's resemblance to ourselves.