[Stackless] Tasklet State RE: (no subject)
Andrew Francis
andrewfr_ice at yahoo.com
Sat Oct 10 22:07:32 CEST 2009
Hello Kristján:
--- On Sat, 10/10/09, Kristján Valur Jónsson <kristjan at 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
More information about the Stackless
mailing list