[Stackless] For the Wiki - Comments on Deadlock and Network Pumps

Andrew Francis andrewfr_ice at yahoo.com
Mon Feb 20 18:31:02 CET 2006

Hello Richard et al:

--- stackless-request at stackless.com wrote:

> Anyone who has an interest in getting more familiar
> with the Stackless internals by helping out with the
> port, or would like to help out in fleshing out the
> web site, tests or documentation would be more than
> welcome to join us in the sprint.  Just join us at
> the sprint for anything Stackless related!

Sorry I can't come to Dallas. However I have intended
to start writing stuff for the Wiki. I would like to
make contributions to the Stackless community.

I am now starting to get the swing of Stackless
Python. In the next few weeks, I would like to write
about my experiences.

For now, I would like to point out some gotchas and
techniques. It would be nice to flesh out ideas before
I summarise on the Wiki.


Often we see the construct:

# number of tasklets running

while (stackless.getruncount() > 1):

print "Finished"

The programme terminates. However the programmer was
sure that there are still tasklets running. What
gives? The problem is that stackless.getruncount()
does not include tasklets that are blocked on

Based on my experiences, this is often a sign of


The main problem in my early programmes is that I
often got deadlock. I am very interested in
understanding how deadlock occurs in a Stackless
programme, and what architectures and techniques to
use to avoid it. I was impressed when Bjarne spotted a
cycle in my code. I realised I drew the graph the
wrong way. There are procedures for drawing resource
allocation graphs and detecting deadlock. Whether this
can be built into Stackless is another question.


Since Stackless is for the most part, based on
cooperative scheduling, there is more opportunity for
a programmer to get into a deadlock situation. A part
of the solution is looking for the situations.

Deadlock occurs only when four conditions are present:

1) Mutual exclusion.
2) Hold and wait.
3) No Preemption
4) Circular wait.

Also processes (tasklets) are competiting for
resources, namely channels.

Here I need a little help from the audience. I will
argue that 

1) Mutual exclusion: only one tasklet has access to
the "cpu" to the exclusion of others.

2) No Preemption: 

a) A running task cannot be pre-empted unless it
blocks or explicitly yields by calling schedule()

b) Outside of performing a read or write, there is no
other way to unblock a blocked task.

3) Hold and wait: 

Blocked tasks hold a resource - a channel.

4) Circular wait:

A tasklets are using two or more channels. The tasklet
is blocked on a channel, and when unblocked, will
perform an transaction on another channel. However due
to transitivity, there is a circular wait. 

In the future, I will illustrate an example with
cycles and solutions. I think this will help both
myself understand the issues better and help new

The Network Pump:

I have been using HTTP client and server classes that
rely on asyncore and asynchat. I have been looking at
Richard Tew's excellent example of the MUD. I find
that I am writing a variation on Richard's code:

class NetworkPump(object):
      def __init__(self)
         self.flag = True
      def pump(self):
          while (self.flag):


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list