[Stackless] Server Components

Michael ms at cerenity.org
Fri Mar 28 16:32:31 CET 2008

On Friday 28 March 2008 13:18:31 Simon Pickles wrote:
> SO - Am I reinventing the wheel? 

Of course you are - you wouldn't ask the question otherwise :-) The question 
is "are you inventing a better wheel"? That's a harder question - that's one 
you can answer, not me :)

> Does Twisted do this, or other 
> Frameworks? In my limited experience, I need to create a server hub then
> have all the component modules connect to that as clients.

Twisted tries to avoid multithreading and multiprocess, so you're probably 
working in an independent space. However it might be worth you thinking how 
you can work with twisted rather than in competition with twisted. ( It may 
take a bit of thought, but I suspect it's doable :)

That's kinda where Kamaelia fails - since for some dumb reason people think 
it's competition with twisted, even though it's aim is rather different. It's 
probably because we started from the starting point of "How do we make 
concurrency easier to deal with for the average maintainer since we're making 
a network server" (which was the original goal), rather than "how do we use X 
to build a network server". The problem is that was taken as competition with 
twisted. (I did give a particularly bad lightning talk once which probably 
didn't help)

Anyhow, kamaelia does do networking stuff in a communicating sequential
things kind of way (which stackless does of course as well), so hopefully the
rest of this is more relevant...

> Is there a better way?

I don't know if it's better, but you may want to look at what we've done in 
Kamaelia. We use generators to build the majority of our components, but do 
also have thread based & process based components. Each communicates to the 
outside world using the same API of inboxes & outboxes (akin to stackless's 
channels), and these are implemented differently depending on the concurrency 
mechanism used.
   * Generators use standard lists
   * Theads uses Queue.Queue's
   * Processes use Paul Boddies pprocess module and the channel's he

Our networking code lives in the following places:

Now you may dislike the coding style or like it. But hopefully it's useful. It 
would be REALLY interesting to see someone create a Stackless base component 
as well, and if you're interested in doing that, our tutorial which teaches 
beginners to python how to build their own core generator based system is 

... since we've often created mini-axon's when building a new concurrency 
mechanism (or working on optimisations/restructures).

Random aside: if a student wants to do something related to this sort of thing 
as part of Google's Summer of Code, please put an application in under BBC 
Research, since Kamaelia is the main focus there. I've put a suggestion of 
stackless integration & twisted integration up on our ideas page, but it's 
probably a good idea to mention it here...


advice for GSOC apps: 

More information about the Stackless mailing list