[Stackless] Channel Deadlock
jmtulloss at gmail.com
Tue Apr 29 20:15:56 CEST 2008
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:
> Thread 2:
> Thread 3:
> 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?
More information about the Stackless