[Stackless] Proposed modification WRT threading and scheduling

Kristján Valur Jónsson kristjan at ccpgames.com
Tue Apr 1 12:02:50 CEST 2008


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.

Comments?

K

> -----Original Message-----
> From: stackless-bounces at stackless.com [mailto:stackless-
> bounces at stackless.com] On Behalf Of Richard Tew
> Sent: Wednesday, January 09, 2008 08:26
> To: Stackless mailing list
> Subject: [Stackless] Proposed modification WRT threading and scheduling
>
> Hi,
>
> As I don't normally use Python threads with Stackless, I wasn't totally
> familar with how they worked together.  I assumed that since each
> thread can run a scheduler, the threads would then just schedule away
> independently.  However, this is not the case.
>
> When the scheduler is run, when there are no remaining tasklets
> scheduled and there are other Python threads which are runnable, then
> the scheduler will not exit and will instead block indefinitely waiting
> for one of those threads to reawaken it.  You can see this demonstrated
> in the attached script, where the main thread will block instead of
> exiting the scheduler.
>
> I'd like to make a change to Stackless to optionally disable this
> behaviour, perhaps an option which can be set on the stackless module,
> or a parameter to the 'stackless.run' function.
>
> Any thoughts?  Comments?
>
> Cheers,
> Richard.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slthread.py
Type: application/octet-stream
Size: 238 bytes
Desc: slthread.py
URL: <http://www.stackless.com/pipermail/stackless/attachments/20080401/9b86cb49/attachment.obj>


More information about the Stackless mailing list