[Stackless] ignore_nesting

Jeff Senn senn at maya.com
Wed Feb 12 13:42:39 CET 2014


I haven’t looked at this in ages, but at some point I had to go to the trouble of passing this as true to stackless.run() in the top level scheduler
of my app because I discovered that someone using ‘exec’ inside a tasklet could monopolize the scheduler (could not switch
until the exec completed).

I admit that I don’t understand it fully (or even "very much" without going to refresh my memory)
and I assume by “go away” you mean: make the switching more “aggressive” by aways assuming that ignore_nesting is true.

-Jas

On Feb 12, 2014, at 5:14 AM, Kristján Valur Jónsson <kristjan at ccpgames.com> wrote:

> Hello there.
> I have a question regartding stackless.run()
>  
> This function has an „ignore_nesting“ boolean keyword.  Individual tasklets also have a „ignore_nesting“ flag.  The keyword arg implies „ignore_nesting“ as being true for all tasklets.
> My question is this:
> What is the use case for this?
> If ignore_nesting is effectively false for a tasklet, then it will not be (hard) interrupted if it has a „nesting level“ higher than 0.  This means one of two things:
> 1)      It is running as a separate hard switching tasklet (i.e. soft switching is not enabled)
> 2)      Soft switching is enabled but the tasklet will need hard switcing, e.g. because it is running in a nested „frame evaluation loop“, because it has called through a C api.
>  
> My question is more this, why would we have this limitation on interrupts?  And why make it the default?  
> What is more, is the author of code in a position to know beforehand if a tasklet will have a posisitive nesting-level?
>  
> Note that code can prhohibit interrupts by using the atomic flag (although this will also have the side effect of prohibiting thread switches).  the ignore-nesting flag will _allow_ interrupts that would otherwise be automatically prohibited because of the nesting level.
>  
> I think this nesting_level busininess for the watchdog is confusing and would like to see it go away, but for that we need to understand why it was put in place in the first place.
> K
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20140212/6aecdc9f/attachment.html>


More information about the Stackless mailing list