Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)

[Johnathan Corgan]

On 2/5/08, Johnathan Corgan <address@hidden> wrote:

> Firas Abbas wrote:
>
> > Yes. The GNU Radio is working. Only when I run the sequence tb.start() ,
> > tb.stop() then tb.start() in the running python code, I get this problem
> > [I cannot run tb.start() two times].
>
> This actually sounds like a new, different issue; I'll look at this today.

This issue has been fixed in r7565 on the trunk, however there is a
clarification needed.  The specific issue, an abort instead of a
Python exception, was because the SWIG compiler was not told that the
underlying C++ code could throw an exception, so it wasn't being
handled correctly.

However, it is correct behavior to throw an exception in the above scenario.

The semantics of running a GNU Radio gr.top_block have give the user
two different options:

1) Use gr.top_block.run().  This will cause the flowgraph to be run in
a separate thread (possibly multiple threads), and block the mainline
thread until either the flowgraph ends on its own, or an exception
occurs (like a CTRL-C generated SIGINT.).  Everything is handled
automatically for the user.  Most of our non-GUI example applications
use this option.

2) Use gr.top_block.start().  This will cause the flowgraph to be
started in a separate thread (possibly multiple threads), then control
immediately returns to mainline thread context.  This allows the
application to do other things in parallel with the flowgraph.  All
the GUI-based examples use this (the flowgraph management is actually
handled for the user in gr-wxgui.)

In the case of #2, at some point the flowgraph must be stopped.  The
application first calls stop().  This signals all the flowgraph
threads to exit their next opportune moment.  Then the application
calls wait(), to allow all the threads to actually do so.  At this
point the flow graph can be restarted (if needed) by calling start().
The exception in the original problem report was caused by not calling
wait in between.  Note that this is different behavior from the old,
Python-based flowgraph code*.

With the current trunk now:

$ python
Python 2.5.1 (r251:54863, Oct  5 2007, 13:50:07)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from gnuradio import gr
>>> tb = gr.top_block()
>>> tb.start()
>>> tb.stop()
>>> tb.start()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py",
line 45, in start
    self._tb.start()
  File 
"/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py",
line 1461, in start
    return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(*args)
RuntimeError: top block already running or wait() not called after
previous stop()
>>> tb.wait()
>>> tb.start()
>>> tb.stop()
>>> tb.wait()
>>>
$

*The fix for ticket:211, changeset r7053 last November caused this
divergence by moving the change in running status from stop() to
wait().

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com/