[Stackless] Modelling simulated time and granular interruptions

Wolfgang Lipp paragate at gmx.net
Thu Jul 6 20:47:02 CEST 2006






On Wed, 05 Jul 2006 23:04:09 +0200, Grant Olson <olsongt at verizon.net>  
wrote:

...
>> ours, you never know.
>>
>> does that make sense to you?
>>
>> _wolf.
>
> I'm not exactly sure what you're saying here, but the default concurrency
> model in stackless is cooperative.  That does create potential for some
> coupling if there is a misbehaving tasklet that doesn't cooperate  
> correctly.
> The advantage though, is that things are deterministic and easier to
> understand, even if it's not a perfect model of reality.
>
> Or am I not getting your point?
>
> -Grant

as far as i understand the question and its answer, it was not so much  
about the
stackless infrastructure, on which i agree with you, but about the question
how to structure a problem at the application level. this is different, as
different as python and most peoples' cpus, which are strictly serial and  
still
make a lot of things go on seemingly at the same time. so cooperativeness  
on the
part of stackless does introduce some amount of ininhibitable coupling in  
the
model. but whether that should be enforced or relaxed is another question.
as for my part, i am afraid i can't say i find a situation with 50 actors
very deterministic and easy to understand. the three body problem and the
even the `double pendulum
<http://www.maths.tcd.ie/~plynch/SwingingSpring/doublependulum.html>`__
go way beyond what i perceive as determinable. but then, so sometimes do
my own lines of code.

_w.

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



More information about the Stackless mailing list