[Stackless] Stackless based replacement
senn at maya.com
Fri Oct 17 17:35:32 CEST 2008
I've been vaguely watching this discussion -- and I think there might
be a bit
of a communication mismatch.... pardon me if I'm wrong -- I'm probably
not paying enough attention...but....
Stackless was not really designed to be the "OS kernel layer" to a
everyone-writes-their-own-tasklets-they-all-run-together sort of system.
Stackless started as a sort of non-religious set of smallest changes to
C-Python to allow you to build many such systems of different kinds.
(along lots of dimensions: preemptive/cooperative, coroutines/micro-
resource-driven, priority-managed, arbitrary generator, producer/
So, Larry, I think if you say "I want Stackless to be X" -- the folks on
this list are vaguely going to think... "well it can already do that;
just need to write some python code and then standardize on it",
and you would respond (somewhat correctly): "Well, *that* isn't
very user-friendly; nor is it a very good architecture!"
Stackless does sort of suffer, in explanation, by not having a
*standard* and *prominent* more abstract layer...
very early on there was a "uthread" module that was such a thing...
now there are lots of different "demos" floating around...
On Oct 17, 2008, at 10:33 AM, Larry Dickson wrote:
> Hi Andrew,
> We seem to have different ideas of what is simple. You propose
> exceptions, waits, signals, barriers, re-initialization, and
> presumably global signal values. This in my opinion is a whole
> Italian restaurant of spaghetti, and it sounds intrinsically global,
> which is poison to maintainable multiprocessing in my experience. Of
> course I could be wrong, having little experience with your way of
> doing things, except for standard C/Linux signals. (Have you ever
> tried setting anything up with occam manager and workers?)
> The beauty of toplevel (stackless in the generic sense) processes
> communicating through channels is that they do not have to share
> resources OR KNOWLEDGE with other black boxes of the same
> construction but totally different function and/or history. This is
> what drivers try to be but never succeed. A manager based on ALT (or
> stackless_receive_first) can manage several of these black boxes -
> possibly of completely different types, like ethernet and disk - and
> apply optimal strategies to the data flow without digging deep into
> the driver code. But it has to be toplevel, not nested down deep
> like standard drivers.
More information about the Stackless