[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