Example?
> On 25 Jun 2020, at 18:55, Marcus Müller <muel...@kit.edu> wrote: > > Such a thing exists: all blocks have a "system" message port! > >> On 25/06/2020 13.40, Steven Gillies wrote: >> Thanks Kevin, >> It's good to know what I am trying to do is possible in practice. >> I guess I was hoping for some sort of signal I could send that would be >> received by all of the OOT modules in the flowgraph as I think part of the >> problem is that I have a blocking call to accept a socket connection. It was >> when I tried to change this to a non-blocking call that I realised I didn't >> know how to let the loop know to exit (by setting self.is_running=False). I >> tried setting it in __del__(self) but it seems this is never executed. >> In the end through some tinkering I've found that if I start the top_block >> inside multiprocessing.Process and terminate when I'm done then this seems >> to release all of the resources as you describe. Its not as elegant as I >> would have hoped but at least it works for now and I can revisit it if I've >> time. >> For some reason, although it works fine in development, when I deploy it for >> production (inside Docker container) the process will not terminate, and if >> I try to join() then it hangs forever. To solve this I added a timeout and >> if the process is still alive I kill it. >> All in all a bit of a hack, but I've got to start somewhere. >> Cheers, >> Steven >> ------------------------------------------------------------------------ >> *From:* Kevin Reid <kpr...@switchb.org> >> *Sent:* 25 June 2020 04:34 >> *To:* Steven Gillies <stevengill...@outlook.com> >> *Cc:* Discuss-gnuradio@gnu.org <Discuss-gnuradio@gnu.org> >> *Subject:* Re: GNU Radio web API >> On Wed, Jun 24, 2020 at 8:04 AM Steven Gillies <stevengill...@outlook.com >> <mailto:stevengill...@outlook.com>> wrote: >> I am trying to build a web API to start and stop flowgraphs remotely >> and autonomously. >> I am having trouble gracefully shutting down one flowgraph and >> moving on to the next. >> My preferred way implement the services is by running >> top_block.start() from my main thread and allowing it to start its >> own thread. To shut it down I then call top_block.stop() followed by >> top_block.wait(). The threads appear to shut down gracefully but >> when I try to run another flowgraph (either the same flowgraph again >> or a different one) I start to get errors. >> The two error types I get are either; >> 1. that the second flowgraph cannot find the USRP device because it >> is being held by the first ($ uhd_find_devices also returns 'No >> Devices Found' until I exit the main thread at which point it >> finds my B210 again), or >> 2. that a socket that the second wants to bind to is in use by the >> first >> In my experience (I wrote ShinySDR <https://shinysdr.switchb.org/>, which is >> also a web remote control system), the cause of these problems is that >> references to the old blocks still exist. There is unfortunately no standard >> way to tell a block to free the resources it is using, other than ensuring >> it is "deleted" by dropping all references to it. Therefore, you need to >> ensure that your Python code does not have any variables or attributes >> referring to the old top block or the individual blocks, before you >> construct the new blocks. >> That said, you may want to try the alternative of keeping the UHD, socket, >> etc. blocks around and reusing them, and only changing what they're >> connected to. (That's what ShinySDR currently does, though with different >> blocks.) Basically, use disconnect() as well as connect() to change your >> flow graph's connectivity while it's stopped so that it suits the new >> purpose. You might encounter some misbehavior here too, though; this is not >> a frequently used and well-tested part of GNU Radio's capabilities. >
