It might help if you could post the exact flowgraph that you are running, as well as the source code of the main python program.
Aug 20, 2021 14:15:30 Martyn van Dijke <[email protected]>: > Hi Jeff, > > Thanks for the quick response. > > I have tried running the flowgraph.py manually but not after three times, > this is a good point and will try it this weekend to see if that changes the > behavior. > > The behavior does not change based on how long the processes are runned, > adding delays does not change the behavior (leading me to think it's not > necessary resource related) > > I am doing a process.communicate() and a process.kill() to close the process. > > Looking at it more closely now, the problem seems to come source of the > samples not being correct instead of the sink, or at least I think. > Will update after the weekend. > > Sincerly, > > Martyn > > ---------------------------------------- > *Van:* Discuss-gnuradio > <[email protected]> namens Jeff > Long <[email protected]> > *Verzonden:* vrijdag 20 augustus 2021 21:52 > *Aan:* [email protected] <[email protected]> > *Onderwerp:* Re: Executing a flowgraph multiple times from Python > > Sounds like you're running out of some resource. > > What happens when you run flowgraph.py manually (piping in some fixed data if > needed) instead of executing it with Popen? > > Does the behavior change based on how quickly the processes are run? Can you > put in a long delay between packets? > > Are you doing close and wait on the popen object? I don't know exactly what > happens if you don't. > > On Fri, Aug 20, 2021 at 3:31 PM Martyn van Dijke <[email protected]> > wrote: >> Hi everyone, >> >> I am facing a problem and I cannot really figure out what goes wrong. >> >> Some background first: I am working on a ZMQ client <-> broker <-> worker >> setup using GNU Radio (as seen in >> (https://zguide.zeromq.org/docs/chapter4/#Service-Oriented-Reliable-Queuing-Majordomo-Pattern). >> The idea is to package I/Q samples from a GNU Radio client into a network >> packet send it over to the ZMQ Broker route it further there to end up at a >> worker running GNU Radio, unpack it there and use the I/Q samples as a >> source there. (The entire idea behind doing this using a broker is to avoid >> the dynamic discovery problem and being able to eventually aggregate the >> same network packets) >> >> After a lot of coding and figuring out how stuff works I got it to work as I >> wanted, and I have a python program that launches a flowgraph in a new >> process (using python subprocess) and I am able to receive the original I/Q >> samples and process them as one would normally do. >> However, the problem I am facing is that after executing the flowgraph from >> the main python program in a separate process exactly 3 times (tested on two >> machines, multiple times) the flowgraph does not initialize my worker block >> (living inside the flowgraph). The first three times this works without any >> problems, but always on the fourth execution the initialization somewhere >> gets stuck. Specifically, I am using the subprocess.Popen python command to >> open a new flowgraph process. >> >> p = subprocess.Popen(["./flwograph.py"], stdout=subprocess.PIPE, >> stderr=subprocess.PIPE) >> >> After getting the data out of the system each process is stopped and killed >> inside the main python program. Since the flowgraph is being executed in a >> new process and is stopped and killed afterwards there should be no way that >> a previous flowgraph is able to have influence on the current flowgraph (as >> far as I understand it) yet it seems to behave so without a clear cause, >> does anybody have an idea what I am doing wrong or what's going wrong? >> >> I am running GNU Radio 3.9.2 on Arch Linux >> >> Thanks in advance, >> >> Martyn >>
