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

[dhruva <dhruvakm@gmail.com>]

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. For IO intensive usage
using async IO with stackless might make a good candidate.

-dhruva

On 4/30/08, Stephen Eilert <spedrosa@gmail.com> wrote:
> Richard M Stallman wrote:
> >     The other hard problem is multi-tasking in the Emacs Lisp engine.
> >     RMS once left me with the impression that this was virtually
> >     intractable, especially if one wanted to have existing Elisp code base
> >     compatibility, a reasonable thing to want.
> >
> > I think "intractable" might be too pessimistic.  It is certainly
> > a lot of work, but someone could give it a try.
> >
> >
> >
> Before diving in the merits of whether or not it is possible to add
> multi-tasking to Emacs (by that I assume full-blown threads), what are
> the problems this is trying to solve?
>
> Is it to add background processing (as in, file indexing, background
> compilation, downloads and the like)? If then, a notion of task
> priorities could be discussed. For instance, Eclipse knows that, in
> order to deploy an application, it must be compiled first. It
> understands that those tasks cannot happen in parallel and should be
> queued. On the other hand, you can start downloads (usually, plugins and
> updates for said plugins) right away.
>
> It could be a way to use the increasing amount of available processing
> cores in personal computers. Then again, Emacs doesn't seem like a
> particularly CPU-bound application.
>
> So I am at a loss why this is so important. Could someone clarify?
>
>
> Stephen
>
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Contents reflect my personal views only!