Multiple flow graphs, proper design

GNU Radio
1

I have a standalone application, that follows the following pattern:

While True:

2

I have a standalone application, that follows the following pattern:

While True:

x = dequeue()

if X=A

tb = gr.top_block()

<create blocks>

tb.connect(<blocks>)

tb.run()

if X=B

similar but different set of blocks

Is this a right or wrong way to instantiate and use multiple flow
graphs?
I am creating an entirely new top_block() on each iteration, of which
there are 10-20 minute. Over the course of several days, memory
consumption grows and performance slows.

As I try and narrow down the cause, I want to first rule out whether I
am
doing anything wrong on the GNURadio side of the equation by how I am
creating and using multiple graphs.

Thanks

3

On Sat, Jan 7, 2012 at 1:45 PM, Ryan P. [email protected] wrote:

Is this a right or wrong way to instantiate and use multiple flow graphs?
I am creating an entirely new top_block() on each iteration, of which
there are 10-20 minute. Over the course of several days, memory
consumption grows and performance slows.

As I try and narrow down the cause, I want to first rule out whether I am
doing anything wrong on the GNURadio side of the equation by how I am
creating and using multiple graphs.

Thanks

Hi Ryan,
I might have misunderstood what you are doing. So just to be sure, you
create a top block, let it run to completion, then create and run
another
top block until it completes. This continues indefinitely. Right? I just
want to make sure that you want to run these one at a time, in which
case,
what you have here looks fine.

Now to the memory issues. Every time you create a new top block like you
do, it should delete the old one and free up all memory. Obviously, this
doesn’t seem to be happening.

Firs thing to try is to use a “del tb” after the “tb.run()” line to yell
at
Python to delete the object. The probably isn’t the problem, but it’s
easy
enough to try.

If that doesn’t help, see if you can run the program under valgrind and
get
a report of the memory leaks:

valgrind --tool=memcheck python

And see if you can identify where there’s unfreed memory after running a
top block. We have no runtime memory leak problems (since we’ve run
these
things for days and weeks if not longer), but we might not be cleaning
everything up in the end. There are other potential problems with some
libraries we’re linking against. If it’s a problem with GNU Radio, we’ll
obviously work to correct it.

Thanks,
Tom