[Stackless] "Attempt to run a locked frame!"

Christian Tismer tismer at tismer.com
Tue Feb 20 16:48:12 CET 2001

Bernd Rinn wrote:
> On Tue, Feb 20, 2001 at 08:35:33AM -0500, Gordon McMillan wrote:
> > Well after modifying Bernd's code so it works with 1.5.2
> > stackless (and an older uthreads that does not have "wait"), I
> > can report that it runs fine. I simply commented out the
> > uthread.wait and used delay as the select timeout.
> Thank you for pointing out that magic methods may cause problems with
> continuations.
> Can that error occur only when I am doing something stupid like
> calling 'uthread.wait()' from within a magic method or can it also
> occur by chance, when the scheduler decides to perform a task switch
> within a magic method like __init__? What can one do against that? I
> assume using atomic() leaves a little chance that the task-switch
> occurs _before_ or _after_ atomic(), so that not even

The above cannot happen, since every recursion blocks by its
uthread_lock variable which defaults to no scheduling.
It can only happen from inside out.

> def __init__(self, ...): atomic(self.myinit(...)
> would be completely safe. Am I right here?


> And: Is there a way to detect if  is running in a recursive
> interpreter?

Well, there is an undocumented way to do this:
Frames have a computed "locked" flag.
Something like this works:

>>> co=continuation.caller()
>>> while co:
... 	if co.frame.locked:
... 		print "locked frame"
... 	co = co.caller

ciao - chris

Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com
Stackless mailing list
Stackless at starship.python.net

More information about the Stackless mailing list