[Stackless] Channels between threads

[Simon Pickles]

Andrew Francis wrote:
> Hi Simon:
>
>   
>> I understand that channel.send will block until a
>> receive is made. 
>> However, this receive is being made in the
>> requesting thread and the 
>> results are successfully received!
>>
>> So why does this code never reach the line "Ready
>> for new work"?
>>
>> Before the ch.send, the balance on the channel is 0.
>> In the receiving code, the balance on the channel
>> after the receive is 
>> 1, even tho the data IS received.
>>
>> Can anyone imagine why this might be? or have I
>> misunderstood?
>>     
>
> Without seeing the rest of the code and output, I
> would recommend you look at what *all* the tasklets in
> the system are doing. Are  all tasklets blocked except
> for perhaps a tick() that prevents the Stackless
> Scheduler from thinking it is deadlocked (when in
> reality it is)?
>
> Remember that when a tasklet performs a send or a
> receive, it is placed at the end of the scheduled list
> and other scheduled tasklets will execute. The
> Stackless scheduler's behavior in conjunction with a
> channel being inadvertently shared could explain why
> you think the balance is wrong (think of a race
> condition occuring). For kicks, do a __reduce__() on
> the channel and see what tasklets are attached.
>
> Cheers,
> Andrew
>
>
>
>
> Never miss a thing.  Make Yahoo your home page. 
> http://www.yahoo.com/r/hs
>
>   
Hi Andrew,

What exactly does the __reduce__ function show in this context?

I am still puzzled why after the receive(), the function doing the 
matching send is still blocked?

Here's some output to illustrate. The two threads attempting to transfer 
the data are called PLAYERMANAGER and DATABASE. I've put lots of 
__reduce__ messages in, logged as Channel Status:

PLAYERMANAGER: Checking AuthSQL for valid player with id: 2
PLAYERMANAGER: Channel Status before SELECT: (<class 
'stackless.channel'>, (), (0, 6, []))
DATABASE: Putting new request into SQL Work Queue
DATABASE: <SQLWorkerThread(Thread-1, started daemon)> received request 
with channel <stackless.channel object at 0x858c964>: SELECT * FROM 
AuthSQL WHERE id = 2
DATABASE: Executing SQL: [SELECT * FROM AuthSQL WHERE id = 2]
DATABASE: Results in SQLConnection sent to <stackless.channel object at 
0x858c964>: ((2L, 8738L),)
PLAYERMANAGER: Channel Status before receive: (<class 
'stackless.channel'>, (), (1, 6, [<stackless.tasklet object at 0x85452cc>]))
DATABASE: Sending result thru: <stackless.channel object at 0x858c964>, 
balance: 0
DATABASE: Channel Status before send: (<class 'stackless.channel'>, (), 
(0, 6, []))
PLAYERMANAGER: Channel Status after receive: (<class 
'stackless.channel'>, (), (1, 6, [<stackless.tasklet object at 0x85452cc>]))
PLAYERMANAGER: Received result from <stackless.channel object at 
0x858c964> with a balance of 1
PLAYERMANAGER: Entry for id 2 found in AuthSQL with key 8738(0x2222)


The third from last line seems to suggest their is still activity in the 
channel (1, 6, [<stackless.tasklet object at 0x85452cc>]).

What does the 1, 6, and tasklet represent in this case? 1 is the 
balance, 6 is ??? and tasklet is the listening loop?

Not sure this helps much :)

Cheers!


Simon