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".
> 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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
