[pypy-dev] Why is there a separate ExecutionContext?

logistix vze55z8s at verizon.net
Thu Mar 6 07:52:18 CET 2003



> -----Original Message-----
> From: Rocco Moretti [mailto:roccomoretti at netscape.net]
> Sent: Wednesday, March 05, 2003 9:19 PM
> To: logi.stix at verizon.net; "'Armin Rigo'"; pypy-dev at codespeak.net
> Subject: RE: [pypy-dev] Why is there a separate ExecutionContext?
> 
> 
> "logistix" <vze55z8s at verizon.net> wrote:
> 
> >Would it be semantically clearer if PyFrames got an executioncontext
> >object in the constructor instead of the space object?  Space could 
> >still be accessed via frame.ec.space.  
> >Frame.space.getexecutioncontext() seems like you're running 
> in circles.
> 
> Actually, in the interest of generality, I'd argue that
> ExecutionContexts 
> should not contain a link to the object space - it should be 
> a per frame 
> value. If you think of a future time when multiple ObjSpaces 
> coexist in 
> the same interpreter, a frame in one ObjSpace will be able to 
> call a frame 
> in another ObjSpace. Since a function in one ObjSpace can 
> call a function 
> in a different ObjSpace, the ObjSpace for the ExecutionContext is not 
> constant.
> 
> The trick in calling across ObjSpaces is marshaling/demarshaling
> arguments/return values. For now we can deal with it by 
> requiring function 
> calls either to be in the same ObjSpace, or by .wrap()ing and 
> then .unwrap ()ing the values. A more general mechanism can 
> be worked out when we have 
> more than one non-trivial object space.
> 
> -Rocco
> 

I would disagree with this.  It looks like ExecutionContexts are
analogous to threads, so different ec's in the same object space could
interact with each other.  It'd be cool to be able to interact with
other object spaces, but this would be more analogous to a RPC call
operating in an entirely different memory space.  And that's where
marshalling comes in, interaction between different object spaces would
be opaque.

If you try to let the Execution Context cross spaces, even something as
seemingly simple as getting a list of available global variables becomes
a nightmare.



More information about the Pypy-dev mailing list