From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: What's the problem? Date: Thu, 11 Dec 2003 18:09:59 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20031211230959.GA17725@fencepost> References: <87iskpbloe.fsf@mail.jurta.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1071184415 17767 80.91.224.253 (11 Dec 2003 23:13:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 11 Dec 2003 23:13:35 +0000 (UTC) Cc: Juri Linkov , emacs-devel@gnu.org, Miles Bader Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Dec 12 00:13:31 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUZzv-0006VM-00 for ; Fri, 12 Dec 2003 00:13:31 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUZzu-0002Xm-00 for ; Fri, 12 Dec 2003 00:13:31 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AUawG-0008Bu-Ka for emacs-devel@quimby.gnus.org; Thu, 11 Dec 2003 19:13:48 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AUavh-0008Bf-8H for emacs-devel@gnu.org; Thu, 11 Dec 2003 19:13:13 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AUav8-00082g-Qs for emacs-devel@gnu.org; Thu, 11 Dec 2003 19:13:09 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AUav8-00082T-EP for emacs-devel@gnu.org; Thu, 11 Dec 2003 19:12:38 -0500 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.24) id 1AUZwV-0005DE-Uq; Thu, 11 Dec 2003 18:09:59 -0500 Original-To: Stefan Monnier Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Blat: Foop X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18649 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18649 On Thu, Dec 11, 2003 at 09:12:17AM -0500, Stefan Monnier wrote: > > In a cooperative multi-tasking system, you'd just stick in a (yield) or > > something, but in emacs this would be very hard to support. > > I don't see why this should be so hard. What we're talking about is > basically multiple-stacks, context-switches done only from Feval (i.e. at > elisp granularity so there's no concurrency in the C code), some form of > elisp forking and locking primitives Hmmm, aside from application-level issues (which are probably the same whether you use cooperative multi-tasking or a goofy framework like I described earlier), I'd think the most annoying thing would be working around emacs' use of shallow-binding for variables. I.e., for local variable bindings you'd have to unwind the bindings in one thread and wind them in the next when you switched contexts; I'm not sure how non-normal variables would fit into things (presumably you would unwind/wind the the same way, but...). Of course there are other things that behave the same way, like buffer restrictions etc., but maybe they could be treated as `application level' issues, and dealt with via explicit or buffer locking of some sort. If a new `rewind' field were added to unwind-markers on the binding stack, it could identify those that _do_ matter, and say `unwind me when switching thread, and here's how to rewind me later.' Maybe you're right -- if the core changes could be kept fairly small, it would at least be worth experimenting with. -miles -- `Life is a boundless sea of bitterness'