discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Multiple flow graphs, proper design


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Multiple flow graphs, proper design
Date: Sun, 15 Jan 2012 23:21:50 -0500

On Sat, Jan 7, 2012 at 1:45 PM, Ryan Pape <address@hidden> wrote:

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

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 <program>

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


reply via email to

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