[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] making gnuradio blocks entirely in python

From: Johnathan Corgan
Subject: Re: [Discuss-gnuradio] making gnuradio blocks entirely in python
Date: Mon, 26 Sep 2011 09:22:18 -0700

On Mon, Sep 26, 2011 at 09:05, Josh Blum <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]