On Thu, Jun 15, 2006 at 12:35:50AM -0400, Ilia Mirkin wrote:
Quoting M. 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 ™). 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”.
Additionally, python does user threads (cooperative), though they are
probably not what you’re looking for.
Python threads are mapped to pthreads. Unless you take action
(releasing the GIL), only one of them will run at a time. They do
“time slice” between themselves in the python interpreter.
SWIG 1.3.28 and later has an option that will have the wrapper code
drop and then reacquire the GIL. For our scheduler code, we manually
drop
the GIL headed into C++ land, and then reaquire on the way out.
That’s how we run the signal processing in one or more threads, and
the GUI in another.
If you want to see how we handle it, take a look at
gnuradio-core/src/python/gnuradio/gr/scheduler.py
gnuradio-core/src/lib/runtime/gr_single_threaded_scheduler.{h,cc,i}
Eric