On Wed, 2006-06-14 at 22:09 -0700, Eric Blossom wrote: > On Thu, Jun 15, 2006 at 12:35:50AM -0400, Ilia Mirkin wrote: > > Quoting Michael Ford <[EMAIL PROTECTED]>: > > > > > > A somewhat more generic answer than Eric's: > > Thanks Ilia. > > > Python and threads don't mix easily. There's one python interpreter/state, > > and if it's interpreting in one thread, and you try to get it to do > > something > > else from another thread, things will go bad (trying to access state, > > running > > functions, etc may all do Bad Things (tm)). Python 2.4 and up has the > > concept of a GIL (Global Interpreter Lock), which you must acquire before > > doing > > anything else with the interpreter in a thread context. Alternatively you > > can dedicate one thread to synchronize access to the python interpreter. To > > my > > knowledge neither SWIG nor Boost.Python are aware of the GIL, so you must > > acquire/release it for them. > > Actually it's not too bad. The GIL has been around for quite a > while. Pretty sure it was before 2.4. Anyhow, if your threads are > all in python everything "just works".
You're right, the concept of the GIL has been around for a while. But Python 2.4 added a couple of crucial convenience functions: PyGILState_Ensure() and PyGILState_Release() Which allow a thread which doesn't have (direct) access to the interpreter pointer to still be able to run python code. This is particularly useful if instead of spawning an interpreter the interpreter spawns you (e.g. swig/boost.python wrapper dlopen'd by python) and you spawn some threads that still need to deal with the interpter. -Ilia _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
