[Stackless] Proposed modification WRT threading and scheduling

Kristján Valur Jónsson kristjan at ccpgames.com
Tue Apr 1 17:41:15 CEST 2008


I have a patch ready, that needs some more testing.
There are two aspects to this:
1) There is a bug, where calling stackless.run() will block without any possibility of anyone ever unblocking it.  This happens if the main tasklet is the only runnable tasklet.
2) during a stackless.run(), another tasklet (on that thread) will thread block when it tasklet blocks and there is no other tasklet on the thread runnable.  Now, doing this possibly reasonable, but quite possibly not so, if you don't have control over that thread.

I will submit a fix that will fix 1) and amend the 2) with a flag to stackless.run()

K

> -----Original Message-----
> From: Richard Tew [mailto:richard.m.tew at gmail.com]
> Sent: Tuesday, April 01, 2008 12:19
> To: Kristján Valur Jónsson
> Cc: Stackless mailing list
> Subject: Re: [Stackless] Proposed modification WRT threading and
> scheduling
>
> On Tue, Apr 1, 2008 at 6:02 AM, Kristján Valur Jónsson
> <kristjan at ccpgames.com> wrote:
> > It is more serious than that.
> >  I don't think the current behaviour is the way it is for a reason, I
> believe it is bugged.
> >  See the much simpler attached script for a demo.
> >
> >  Basically, if there is another python thread in existence,
> stackless.run() will block.
> >  There is no way that it can ever be unblocked again, because the
> mechanism in schedule_task_block() which normally wakes up the floating
> "Main" after a stackless.run(), is designed to work in the initial
> thread only.
> >
> >  So, even if I had tasklets scheduling away on the worker thread,
> when they 'deadlock' they would never wake up the main tasklet on the
> main thread.
> >
> >  As far as I can see, the only unblocking of threads can occur during
> channel action, which is not what is going on in stackless.run()
> >
> >  Because of this, I think the current behaviour is buggy, and I want
> to make sure that stackless.run() doesn't block.  Fixing that is not
> changing any well designed behaviour.
>
> I believe the intention of this feature is that you will use it
> knowing how it works, and what might go wrong.  There is a lot about
> using Stackless which could be classified this way.  There is also a
> lot about Stackless which is undocumented.
>
> I think the proposed fix is fine.  Make the thread blocking optional,
> but make it off by default.
>
> Anyone want to submit a patch? :-)
>
> Cheers,
> Richard.





More information about the Stackless mailing list