[Stackless] web.py

Richard Tew richard.m.tew at gmail.com
Fri Jun 22 09:17:44 CEST 2007

On 6/22/07, Matt Provost <mprovost at termcap.net> wrote:
> OK I upgraded everything and now I can reproduce a hang. I compiled
> 2.5.1 from svn:
> Python 2.5.1 Stackless 3.1b3 060516 (python-2.51:56057, Jun 21 2007, 22:30:19)
> [GCC 3.4.3 20050227 (Red Hat 3.4.3-22.1)] on linux2

Right, but which branch?  The tag right?  Because the release25-maint
branch is a fork of the mainline Python release25-maint branch.  And
the tag is our fork branched when it was equivalent to the 2.5.1

So it is important to know for sure which you are using.  If it is not
the tag, well, then correct performance is not guaranteed.

> To me it looks like something doesn't like having live tasklets sticking
> around, which is what my code does quite a lot of. Am I doing something
> wrong? Now that I know where it is, I'll poke around in web.py and see
> if anything obvious is going on.

I can't justify spending the time obtaining web.py and running this
until you clarify some issues for me Matt.

How is stacklesssocket involved here?  Normally people import it in
their code and insert it as the socket module.  I don't see how
anything would prevent normal blocking sockets from being used here.

Stackless is a framework, you run it and it takes care of running
tasklets.  You don't run it everytime there is a call.  Even if you
have stacklesssocket in there somewhere, it depends on Stackless being
_the_ primary framework _unless_ you have the primary framework take
over control of management of the asynchronous sockets.  See the first
two functions in stacklesssocket.

managerRunning = False

def ManageSockets():
    global managerRunning

    while len(asyncore.socket_map):
        # Check the sockets for activity.
        # Yield to give other tasklets a chance to be scheduled.

    managerRunning = False

def socket(family=AF_INET, type=SOCK_STREAM, proto=0):
    global managerRunning

    currentSocket = stdsocket.socket(family, type, proto)
    ret = stacklesssocket(currentSocket)
    # Ensure that the sockets actually work.
    if not managerRunning:
        managerRunning = True
    return ret

The tasklets behind the wrapped sockets need to be driven by the
scheduler.  Normally, unless managerRunning is set to True before the
first socket is created, a tasklet is created for this purpose on
creation of the first socket (as shown above).

Now reconcile that with the fact that in your code web.py is the
primary framework.  If it is using the stacklesssocket module provided
sockets through monkeypatching (which I am not seeing, but we will
ignore that) then the sockets wouldn't even be working because nothing
does scheduling except the result of an incoming call.

Glad to see the crash bug is gone though :-)


Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list