On Thu, May 7, 2009 at 1:21 PM, Richard Tew <[email protected]> wrote: > On Thu, May 7, 2009 at 1:17 PM, Manley, Tom <[email protected]> > wrote: >> To hit the assert I start the interpreter from VS2K8, import stackless, and >> then paste the commands into the interpreter. I just tried recreating your >> steps by putting the commands in a script and running it directly, and that >> worked fine, i.e. does not assert. I also tried starting the interpreter >> from VS2K8 and importing the script and it worked there as well. > > Given this, the assertion is harmless. I still need to reconcile > fixes made in different branches, and the fix for this has been made > in py3k branch, and still needs to be merged over. Feel free to > ignore it.
On Thu, May 7, 2009 at 2:04 PM, richard.tew <[email protected]> wrote: > Author: richard.tew > Date: Thu May 7 20:04:08 2009 > New Revision: 72433 > > Log: > Merged r64818 from py3k. > > When a main tasklet is destroyed, it was expected that there wouldn't be a > current tasklet if the recursion count was higher than 0. This is not > correct in the case the tasklet was created by an interpreter command, as > each creates a new main tasklet, and the creation of a new tasklet within > that will leave it in the scheduler as the current tasklet, as the main exits. > > Why did this not error in older versions of Python? I do not know. But the > fix makes sense, and the recursion count being greater than 0 is valid (it > was that way before we created the main tasklet). > > Modified: > stackless/branches/release26-maint/Stackless/module/scheduling.c > > Modified: stackless/branches/release26-maint/Stackless/module/scheduling.c > ============================================================================== > --- stackless/branches/release26-maint/Stackless/module/scheduling.c > (original) > +++ stackless/branches/release26-maint/Stackless/module/scheduling.c Thu > May 7 20:04:08 2009 > @@ -1026,12 +1026,19 @@ > } > > /* update what's not yet updated > + > Normal tasklets when created have no recursion depth yet, but the main > tasklet is initialized in the middle of an existing indeterminate call > stack. Therefore it is not guaranteed that there is not a pre-existing > recursion depth from before its initialization. > + > + Previously, we exited a main tasklet with the expectation that there > would > + be no current one. This is incorrect, and the case of the > interpreter where > + each command creates a new main tasklet to create a new tasklet, > which is > + scheduled (made the current now) but not run yet, means we need to > expand > + this check. > */ > - assert(ts->recursion_depth == 0 || ts->st.main == NULL && > ts->st.current == NULL && prev == next); > + assert(ts->recursion_depth == 0 || ts->st.main == NULL && > ts->st.current != next && prev == next); > prev->recursion_depth = 0; > assert(ts->frame == NULL); > prev->f.frame = NULL; > > _______________________________________________ > Stackless-checkins mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless-checkins > _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
