On Mon, Sep 26, 2011 at 09:05, Josh Blum <[email protected]> wrote: > The implementation is relying on a hairy thing like swig directors. > Shiver...
We've had mixed results with swig directors in the past. The bigger issue here, though is the Python global interpreter lock. This is released by the GNU Radio runtime in top_block.start() and top_block.run() so that the Python calling thread can proceed after GNU Radio kicks off the flowgraph threads. When calling back up to Python, that lock has to be re-acquired, and all other Python threads in operation (including GUI threads for wxPython and QTGui) will block waiting for it to be released. So while this would work in theory, it could create a nasty coupling in application performance between signal processing code and GUI code, and possibly even deadlocks if the non-GNU Radio Python code needed to interact with the Python block. Fortunately, you've done this in a way that can be tested without any modifications to GNU Radio, so we can get some empirical results. I think a more useful area for C++->Python communication is to make it *easy* for a GNU Radio block to notify a Python object that something has happened, possibly with data attached. For example, in the uhd_fft.py and other GUI programs that use the fft sink, we have to end the GNU Radio flowgraph proper in a message sink/message queue, and then have a Python thread run this queue for entries, process them, then post the processed FFT frames to wxPython's GUI thread. This is not only inefficient, but hard to generalize from or even just learn from by inspection. I created the gru.msgq_runner class to help this, but it's still a hack. So a mechanism that takes an arbitrary pmt on the GNU Radio C++ end and results in a function call to a Python bare function or class method with that pmt as the argument would create a generic method to pass events of all sorts up from the "data plane" portion of the app to the "control plane", non-GNU Radio code. Johnathan _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
