Yes. It is indeed the way to go about things. Works much more smoothly and quite a bit faster as well. Thanks.
On Fri, Mar 25, 2016 at 11:26 AM, Kevin Reid <kpr...@switchb.org> wrote: > On Mar 25, 2016, at 7:53, M. Ranganathan <mra...@gmail.com> wrote: > > > Kevin, > > > > Thanks for the answer. My setup is a little more complicated than that. > The sensor reads its configuration from the server. The server could > reconfigure the sensor between restarts. > > > > I did try stopping the task graph and restarting but the problem is > unresolved. I tried ulocking but I get the following: AttributeError: > 'top_block_sptr' object has no attribute '_unlock' > > The method is called unlock, not _unlock. The underscore in my previous > message was for emphasis. I didn't mean to suggest that you should blindly > call unlock(), but as part of a proper flowgraph reconfiguration. Sketch > like this: > > > top_block.lock() > top_block.disconnect(source, whatever_is_next) > top_block.unlock() > source = osmosdr.source(...) > top_block.lock() > top_block.connect(source, whatever_is_next) > top_block.unlock() > > What I meant in my previous message was that line 3 of this example must > be present before line 4 (you can't lock/unlock only once around the whole > thing). This is because the changes don't completely take effect until you > unlock, so the old source is still around. > > You might find it simpler to discard the entire flow graph and rebuild it. > But again, you must make sure that you're not holding on to references to > the source in any direct or indirect way. > > -- > Kevin Reid <http://switchb.org/kpreid/> > > -- M. Ranganathan
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
