PyThreadState_Swap difference in 2.3.2?

Paul Miller paul at fxtech.com
Tue Dec 16 16:22:52 CET 2003


>Unfortunately, much of this stuff has never been thought through 
>correctly.  Trying to work with multiple InterpreterState objects is 
>also very difficult, and in some cases simply does not work, as not all 
>global variables are stored in an InterpreterState.  Theoretically 
>though, this is probably what you want - if a different InterpreterState 
>is current, I would expect a ThreadState specific to the 
>InterpreterState could be used - but I doubt it works <wink>

It used to work perfectly in 2.2. Thus my dilemma. 

>The easy answer is to stop trying to create multiple interpreter states, 
>then use the PyGILState calls to manage your thread-state.  These should 
>be 2 lines per function (rather than the many that exist now).  If you 
>need to build in both pre 2.3 and 2.3+:

But, I'm not looking for a replacement for per-thread state. I am actually
maintaining multiple *interpreters*, each with all those global variables
you talked about. I need to do this because I want to be able to create an
"environment", load some scripts, run them, then delete that "environment"
without affecting other "environments".

If this PyGILState actually is an entire Python interpreter environment,
then I'll happily switch to it.






More information about the Python-list mailing list