From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Hansen Newsgroups: gmane.emacs.devel Subject: Re: Very interesting analysis of "the state of Emacs" Date: Thu, 01 May 2008 08:31:45 +0200 Organization: disorganized Message-ID: <87ve1ypmb2.fsf@localhorst.mine.nu> References: <481693C3.70901@emf.net> <4816CDB6.6000006@pajato.com> <4817D79F.8040508@gmail.com> <874p9jhsa7.fsf@localhorst.mine.nu> <87bq3qodp4.fsf@bar.jrock.us> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1209623920 24409 80.91.229.12 (1 May 2008 06:38:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 May 2008 06:38:40 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 01 08:39:16 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 1JrSRn-0006x9-95 for ged-emacs-devel@m.gmane.org; Thu, 01 May 2008 08:39:15 +0200 Original-Received: from localhost ([127.0.0.1]:35105 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JrSR6-0007HO-A5 for ged-emacs-devel@m.gmane.org; Thu, 01 May 2008 02:38:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JrSR2-0007Fw-I0 for emacs-devel@gnu.org; Thu, 01 May 2008 02:38:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JrSR0-0007FV-Ee for emacs-devel@gnu.org; Thu, 01 May 2008 02:38:27 -0400 Original-Received: from [199.232.76.173] (port=40376 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JrSR0-0007FS-Bo for emacs-devel@gnu.org; Thu, 01 May 2008 02:38:26 -0400 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JrSQz-0005r6-Q8 for emacs-devel@gnu.org; Thu, 01 May 2008 02:38:26 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JrSQs-0005AR-Af for emacs-devel@gnu.org; Thu, 01 May 2008 06:38:18 +0000 Original-Received: from e178009070.adsl.alicedsl.de ([85.178.9.70]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 May 2008 06:38:18 +0000 Original-Received: from david.hansen by e178009070.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 May 2008 06:38:18 +0000 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 41 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: e178009070.adsl.alicedsl.de Mail-Copies-To: nobody User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:loMa/2cXHLeLKRZAsrAYNRSurCk= X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:96265 Archived-At: On Wed, 30 Apr 2008 23:23:03 -0500 Jonathan Rockway wrote: > But of course... what do you do for things that can't be copied, like > buffers or window layouts? What happens if something like this > executes in parallel: > > A (some-slow-function) (goto-char 42) > B (save-excursion (goto-char 0) (do-something)) > > And the execution order happens to be: > > (goto-char 1234) > A (some-slow-function) > B (save-excursion (goto-char 0) > A (goto-char 42) > B (do-something) > B ) > > Where is the point now? Logically it would be at 42, since the > save-excursion shouldn't have moved it... but the save-excursion sets it > back to the initial value of 1234 when it unwinds. This makes sense > when you look at the execution order, but that's non-deterministic so it > will never be consistent. > That's exactly why I think co-routines are the way to go. You just don't `yield' within a `save-excursion' (the macro could even flet it to some NOP). And if you do `yield' you know exactly that you can't rely on some state before it. I don't think globals are a huge problem. It's either some internal state of a package. Then it's just the job of the programmer of the package to be more careful. Or it's some user setting, then you have to let bind it at the beginning of your lengthy calculation. (let ((option *user-setting*)) (do-lots-of-stuff)) This would be a rare exception anyways, most commands are short and fast and won't `yield' at all. David