emacs-devel
[Top][All Lists]
Advanced

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

Re: What's the problem?


From: Miles Bader
Subject: Re: What's the problem?
Date: Thu, 11 Dec 2003 18:09:59 -0500
User-agent: Mutt/1.3.28i

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'




reply via email to

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