Hello Kristján:
--- On Sat, 10/10/09, Kristján Valur Jónsson <krist...@ccpgames.com> wrote:
> I must agree with Richard.
Fair enough. Look at the code" approach is a part of Stackless culture.
> However, I have already done this research to a small
> degree when I was writing code to explore deadlocks in eve.
> Here is a snippet that prints out information about a
> tasklet, this is from a subclass of stackless.tasklet:
> def __repr__(self):
> abps = [getattr(self, attr) for
> attr in ["alive", "blocked", "paused", "scheduled"]]
> abps = "".join(str(int(flag))
> for flag in abps)
> return "<TaskletExt object
> at %x, abps=%s, ctxt=%r>"%(id(self), abps,
> getattr(self,'storedContext', None))
However Kristján I don't see that code fragment in the 2.6.2 source code base.
Nevertheless, thank you for the answer
> the documentation for the four attributes is in the
> source. blocked paused and scheduled are not independent.
> a tasklet can be either blocked or paused, not both.
> and if it is, it is not scheduled.
....
>From my knowledge of the scheduling algorithm, I thought the states were
>simpler - runnable (tasklet is on the runnable list), blocked,
currently running, and implicitly just starting and dead/finished.
But yes I took a look in tasklet.c. And yes if I looked at the code, we could
been spared this discussion. I didn't know about 'paused.' Alive can encompass
multiple states.
I don't want to be critical, but I would have expected a 'state' that has
enumerated and mutually exclusive states. I believe a 'state' variable would
make things simpler for programmers.
I will try to draw a state machine and include it in my final slides. That way,
new programmers will know.
Cheers,
Andrew
_______________________________________________
Stackless mailing list
Stackless@stackless.com
http://www.stackless.com/mailman/listinfo/stackless
