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
generic
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-
thread,
resource-driven, priority-managed, arbitrary generator, producer/
consumer etc...)
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;
you
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...
-Jas
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.
Larry
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
