[Stackless] Stackless based replacement

Jeff Senn 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  
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




More information about the Stackless mailing list