[Stackless] Channel Deadlock

[Justin Tulloss]

On Tue, Apr 29, 2008 at 1:15 PM, Justin Tulloss <jmtulloss at gmail.com> wrote:
> On Tue, Apr 29, 2008 at 10:11 AM, Andrew Francis <andrewfr_ice at yahoo.com> wrote:
>  >  Out of curiosity, do you need real OS threads to wait
>  >  for incoming messages? I found it tricky to mix
>  >  Stackless with OS threads so I avoid it. Moreover, I
>  >  think the behaviour of threads with Stackless has
>  >  changed.
>  >
>  I could probably do it asynchronously, but I'm using stackless on top
>  of a rather complex routing overlay that uses threads its internal
>  implementation. It calls back into my python code out of a receiving
>  thread. I don't really want to change its behavior.
>
>
>  >
>  >  Justin, what Stackless does not like is when the main
>  >  tasklet is blocked. Simple example
>  >
>
>  I actually found where I was indefinitely blocking my message
>  processing tasklet while trying to deliver more messages. Silly me.
>
>  One last question, how thread-safe are channels? For instance:
>
>  Thread 1:
>  Tasklet 1:
>     while True:
>         channel.receive()
>         process_stuff()
>
>  Thread 2:
>     channel.send()
>
>  Thread 3:
>     channel.send()
>
>  If thread 2 and 3 execute at the same time (or as same time as you can
>  get with the GIL), I assume that the above example is still safe.
>  Let's assume thread 2 wins the race. First tasklet 1 is started in
>  thread 1, and then the tasklet runs in thread 2 since it won the race.
>  Thread 3 blocks. The tasklet is done processing, it loops back and
>  receives on the channel again, thereby unblocking thread 3 and
>  resuming execution within thread 3.
>
>  Am I interpreting how this works correctly? Is this safe?
>
>  Thanks,
>  Justin
>