emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Very interesting analysis of "the state of Emacs"


From: David Hansen
Subject: Re: Very interesting analysis of "the state of Emacs"
Date: Thu, 01 May 2008 00:49:52 +0200
User-agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.60 (gnu/linux)

On Wed, 30 Apr 2008 18:00:49 -0400 Richard M. Stallman wrote:

>     If we are looking at concurrency, there is another paradigm based on
>     maintaining multiple internal function call stacks which a scheduler
>     can schedule in some fair fashion. I am talking of stackless Python
>     implementation. You really do not have multiple threads but get
>     simulated concurrency through stack switching.
>
> The idea is to get effective parallel execution for Lisp programs and
> redisplay.  This doesn't mean using multiple threads at the C level.
> It means using whatever method is convenient.

I don't think we would even need a scheduler, co-routines and something
like a `yield' function seem to be perfectly fine.  This would also
minimize the risk it breaks existing code (though existing code would
still block emacs, but that's a transition that can be made over time
when needed).

I would strongly oppose OS level threads.  It's just to easy to fuck
things up and I think elisp should keep things simple.

There are some small languages that implement this (e.g. Lua or Scheme
(not in the standard but it's a natural use for continuations)).  The
main problem I would see is emacs dynamic scope, e.g. what's the value
of a variable in one thread if another one let binds it.

David





reply via email to

[Prev in Thread] Current Thread [Next in Thread]