[Stackless] The Future of Stackless

Andrew Francis andrewfr_ice at yahoo.com
Sat Dec 29 23:56:29 CET 2007

Hi Carlos:

> In this module, we will have one process per core
> and one stackless scheduler for each. Each process
> will have a manager tasklet that acts as an IO
> dispatcher and a tasklet manager. It sends the newly
> created tasklets to the other processes and manages
> them. The channel communication is done with one
> channel in each side and some kind of Ipc to bridge
> them. When a tasklet sends something using a
> channel, it gets blocked as usual but its data is
> sent to the other process and awaits in the new
> channel.
> This is a rough idea and I don't know exactly where
> to start and how to do some stuff. Do you guys seem
> this idea feasible?

I have started to read more on the subject myself....

However I would start by looking at the Nancy Lynch
book "Distributed Algorithms" to get a feel for the
issues and the formalisms. Even if you don't use
Lynch's model, you get exposure to the theoretical
computer science....

As I stated in an earlier post, the Stackless
scheduler can be described in terms of a global
synchronizer. In turn, it is possible to partition a
global synchronizer into a hierarchy of of local
synchronizers that communicate through channels. 

Again, I may be talking through my hat. However I
don't see why a physical processor cannot be allocated
to local synchronizer, simple spin locks are used to
safeguard stuff like communication mechanisms (i.e.,
channels), and the scheduler rather than the GIL, is
used to guarantee mutual exclusion. This approach may
work for coarse grained applications at a fraction of
the cost of a more comprehensive solution.


Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

More information about the Stackless mailing list