[Stackless] Proposed modification WRT threading and scheduling

[Richard Tew]

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.