[Stackless] web.py

Matt Provost mprovost at termcap.net
Fri Jun 22 13:03:10 CEST 2007

On Fri, Jun 22, 2007 at 07:17:44AM +0000, Richard Tew wrote:
> 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
> release.
> 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.

I just did:
svn checkout http://svn.python.org/projects/stackless/tags/python-2.51/
so I guess that's the tagged release.

> >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.

I guess I wasn't that clear in my latest email, but I think the
stacklesssocket problems were a false alarm. I tried porting over my
existing code which uses it and it was returning errors, but then I
reinstalled the new versions of everything and stripped it down until I
could reproduce the hang, which doesn't appear to have anything to do
with stacklesssocket. The code I posted is all it takes to reproduce the
hang, everything else is standard.

> 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.
>        asyncore.poll(0.05)
>        # Yield to give other tasklets a chance to be scheduled.
>        stackless.schedule()
>    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
>        stackless.tasklet(ManageSockets)()
>    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 :-)

It seems pretty possible that it's the clash of the two frameworks, as
you say. I'm not looking for someone to totally debug the problem, I was
just checking to see if anyone had ever gotten stackless to work with
web.py. So far it appears not. Hopefully I'll be able to figure out why
and let everyone know.

Thanks for taking a look!

Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list