[Stackless] Santa concurrency problem

Brian Zimmer bzimmer at ziclix.com
Wed Mar 28 20:39:20 CEST 2007


But my problem with that one is the example I followed up with where IO 
was occurring in another thread.  Since the stackless scheduler knows 
nothing about the IO events being send to the channel the channel can 
not be read until the stackless thread wakes up.  That turned me off.  
This definitely appears to be an issue of understanding the app's 
requirements and coding to those rather than offering one catch all 
solution.

thanks, brian

On Mar 28, 2007, at 11:07 AM, Carlos Eduardo de Paula wrote:

> Brian,
>
> the last proposed example by richard, where the Sleep manager sleeps
> while there are no tasklets sleeping is better then the fixed
> time.sleep(0.001) one... try it out:
>
> def ManageSleepingTasklets():
>     while True:
>      if len(sleepingTasklets):
>        endTime = sleepingTasklets[0][0]
>        if endTime <= time.time():
>          channel = sleepingTasklets[0][1]
>          del sleepingTasklets[0]
>          # We have to send something, but it doesn't matter what as it
> is not used.
>          channel.send(None)
>        elif stackless.getruncount() == 1:
>          # We are the only tasklet running, the rest are blocked on
> channels sleeping.
>          # We can call time.sleep until the first awakens to avoid a 
> busy wait.
>          delay = endTime - time.time()
>          #print "wait delay", delay
>          time.sleep(max(delay,0))
>      stackless.schedule()
>
> Carlos
>
>
> On 3/28/07, Brian Zimmer <bzimmer at ziclix.com> wrote:
>> I removed all the wxPython code but it still exhibits the same
>> behaviour as the original sleep in that it pins a cpu in a busy wait.
>> The best overall solution appears to be (in my limited understanding 
>> of
>> Stackless) the tiny sleep 0.001 seconds because it doesn't appear to
>> significantly change the behaviour of the application and keeps the
>> stackless process out of the top spot in top.  Of course this is 
>> highly
>> dependent on the application, as I'm learning.
>>
>> thanks, brian
>>
>> On Mar 28, 2007, at 09:16 AM, Christian Tismer wrote:
>>
>>>
>>> On 28.03.2007, at 17:54, Greg Hazel wrote:
>>>
>>>>> The code uses a bit of wxPython, but that can be removed.
>>>>
>>>> Just a warning - Stackless and wxPython likely have problems 
>>>> together.
>>>> With greenlets, wxYield can cause serious errors, since it does 
>>>> stack
>>>> swapping of it's own. On Windows, at least.
>>>
>>> Sure, there is a load of things to avoid with wx.
>>> Mouse events for instance are (were 2 years ago) living
>>> as a local variable on the stack, so if you want a tasklet
>>> driven mouse driver (which is very nice), you need to
>>> save all mouse status in an extra object and pass that to
>>> the driver.
>>> wxYield I know nothing about, but using concurrent
>>> stack switching approaches is of course a bad idea.
>>>
>>> As said this example is not about wx, but some idea
>>> how to patch time-aware behavior into stackless.
>>>
>>> ciao -- chris
>>>
>>> _______________________________________________
>>> Stackless mailing list
>>> Stackless at stackless.com
>>> http://www.stackless.com/mailman/listinfo/stackless
>>>
>>
>>
>> _______________________________________________
>> Stackless mailing list
>> Stackless at stackless.com
>> http://www.stackless.com/mailman/listinfo/stackless
>>
>
>
> -- 
> -------------------------------------------------------------------
> Visit Stackless Examples Project
> http://code.google.com/p/stacklessexamples/
> Stackless Python - www.stackless.com
> -------------------------------------------------------------------
>
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
>


_______________________________________________
Stackless mailing list
Stackless at stackless.com
http://www.stackless.com/mailman/listinfo/stackless



More information about the Stackless mailing list