Glad you cleared that up, but unfortunately this isn't the fix to my
problem. The flowgraph for some iterations (seemingly random) still stalls
so that I have to hit 'Ctrl-C' to get it to move on.
To be more clear on the "random" stall, here is what happens. I have 10
different simulation iterations I want to run on the base radio. The
parameter I change is the injected noise standard deviation between each
iteration. Sometimes, the script will make it through all 10 runs with no
issue. If I run the script again, the 2nd and 8th iteration might stall.
Now I run it again, and only the 4th stalls. I run it again and I get no
stalls. I run it again and the 5th and 6th stall. It's behavior like this
that I'm seeing.
In between each for loop iteration, I'm doing this in Python:
for n in xrange(0, 10):
tb = top_block()
tb.start()
tb.wait()
tb.stop()
tb.wait()
tb = None
I'm guessing at this point I'm on my own. If anyone knows of a good bit of
info I should have when making these multi-run simulations in python,
please let me know.
Apprecaited,
Rich
On Wed, Nov 11, 2015 at 1:35 PM, Johnathan Corgan <[email protected]>
wrote:
> On Wed, Nov 11, 2015 at 10:59 AM, Richard Bell <[email protected]>
> wrote:
>
>> John, did you mean this four step process, otherwise stop before wait
>> doesn't let anything happen:
>>
>> tb.start()
>> tb.wait()
>> tb.stop()
>> tb.wait()
>>
>> Like that? If so, why don't the auto-generated top_blocks have to do that?
>>
>
> To clarify what is happening under the hood here, let me go through what
> these calls actually do.
>
> tb.start() creates and runs a thread for each block in the flowgraph, and
> immediately returns to the foreground thread execution. One uses this form
> when one wants to continue to do other things in the application while the
> flowgraph is running in the background. This is typically used with GUI
> applications that have their own event loop thread.
>
> At the end of the application, one must call tb.stop(), which issues a
> cancel to each thread, and then tb.wait(), which joins each thread and
> ensures everything is cleaned up before continuing.
>
> Now, flowgraphs can either exit on their own, such when a finite data
> source is used, or a head() block is in place, or they run indefinitely.
> In either case, if the flowgraph is started with tb.start(), it must
> eventually be followed with tb.stop() and tb.wait().
>
> The alternative, which is more common in non-GUI scripts, is to use
> tb.run(). This will internally call start(), and then block either until
> the flowgraph to exits on its own, or a SIGINT (ctrl-c) arrives. It then
> calls tb.stop() and tb.wait() internally, then returns.
>
> Thus, the simpler tb.run() semantics let you create a flowgraph, let it
> run till exit, or break out of it with SIGINT. When tb.run() returns,
> there is nothing else the user needs to do. Hence, many command-line
> examples you see in GNU Radio use tb.run(). If they use the tb.start()
> method, which again, returns immediately to the foreground, they usually
> have a raw input call or something else that blocks until the user does
> something, then they call tb.stop() and tb.wait().
>
> It sounds like what you are trying to do, if I understood correctly, is
> run a finite-length flowgraph over and over again. For that, tb.run()
> should suffice. If the flowgraph is not guaranteed to exit on its own,
> then you'll need to do tb.start(), block while you figure out whether
> conditions are proper for terminating the flowgraph, then do tb.stop() and
> tb.wait().
>
> --
> Johnathan Corgan
> Corgan Labs - SDR Training and Development Services
> http://corganlabs.com
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
