Re: [wxPython-users] Problems in using wxPython in a multithreaded context‏

[Robin Dunn]

Python User wrote:
> I tested to use a single  wxApp and a single MainLoop for my application 
> and it seems to work.
> My C application use many threads and many interpreters and I cannot use 
> many processes.
> 
> Now, I generate my UIs with the global function wx.CallAfter in the 
> thread of the MainLoop (so in the first interpreter)  and with 
> wx.CallAfter I can use data and methods from other interpreters. I may 
> import new modules and change values in the thread of the mainLoop.
> Now my C Code  becomes :
> {
>     PyEval_InitThreads();
>     Py_Initialize();                      //First interpreter
> 
>      PyImport_ImportModule("myModule");//I create a wxApp + UIs + 
> MainLoop in a new thread
>     
>      Py_NewInterpreter()               //second interpreter
>      PyImport_ImportModule("anotherModule");     //I create and print my 
> UI with wx.CallAfter
> ....
> }
> 
> I would like to know if objects which are created or loaded from an 
> event in the UI of the second interpreter are located in the second 
> interpreter or in the interpreter of the MainLoop.
> 

I don't know.  Try adding something to __builtins__ or sys.modules or 
some other place in the 2nd interpreter and then check if it is still 
there in one of the event handlers in the in the code for the 2nd UI.

BTW, the Python docs say this about using Py_NewInterpreter:

"""
Bugs and caveats: Because sub-interpreters (and the main interpreter) 
are part of the same process, the insulation between them isn't perfect 
-- for example, using low-level file operations like os.close() they can 
(accidentally or maliciously) affect each other's open files. Because of 
the way extensions are shared between (sub-)interpreters, some 
extensions may not work properly; this is especially likely when the 
extension makes use of (static) global variables, or when the extension 
manipulates its module's dictionary after its initialization. It is 
possible to insert objects created in one sub-interpreter into a 
namespace of another sub-interpreter; this should be done with great 
care to avoid sharing user-defined functions, methods, instances or 
classes between sub-interpreters, since import operations executed by 
such objects may affect the wrong (sub-)interpreter's dictionary of 
loaded modules. (XXX This is a hard-to-fix bug that will be addressed in 
a future release.)

Also note that the use of this functionality is incompatible with 
extension modules such as PyObjC and ctypes that use the PyGILState_* 
APIs (and this is inherent in the way the PyGILState_* functions work). 
Simple things may work, but confusing behavior will always be near.
"""

Not only is wxPython composed of several extension modules with some 
global variables, but it also uses the PyGILState_* APIs.  So be warned. 
  If you can find another way to accomplish what you need I would 
suggest doing it.


-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!