Jerry James writes:
The word "stackless" appears to be a misnomer. Any idea
where that
came from?
From a particular implementation of Python called "Stackless
Python".
It's been around for many years, but Guido consistently refuses to
put
it into CPython, I don't know why offhand. It has a number of
supporters besides its author, though, and is well-debugged.
1. You have to choose between two painful alternatives.
a. [...]
b. A scheduler that only runs inside of well-defined functions, meaning
that a given stack can hog the CPU for arbitrary amounts of time.
It's not obvious to me that this wouldn't be a big win in XEmacs.
This isn't a realtime OS where you need to discipline badly-behaved
threads; it's a single-user application where judicious use of
cooperative multithreading might permit big wins from a few tweaks.
2. If you choose 1a, then you wind up doing all the work you would
have
to do for a "real" thread library anyway.
Agreed.
3. There are several mature, well-debugged thread libraries out
there. Why
ignore them and start the development and debugging process all over
again?
Because threads are hard. I could see using threads for certain
subsystems (eg, redisplay, and assuming Marcus and Olivier are up for
it, GC), but having true threads in the Lisp interpreter will be hard
(unless we're willing to replace the whole thing).
5. The world is going multi-core. Intel is talking about having
80-core
processors available in 2 years.
Why wait for Intel? You probably already have a couple lying around
(cf this month's ACM Queue---wow! an interview with Tom Duff and he's
not even the focus of attention? Yikes!)
I am interested in having a discussion on what it would take to
switch from our Reactor-based architecture to a multithreaded one.
Such a switch would have serious implications for the Lisp engine
and the garbage collector, for example.
Well, I have to admit that I will have very little useful to
contribute, but I'd be happy to watch and cheer from the sidelines!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta