[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.
> -----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
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 238 bytes
More information about the Stackless