[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