Re: Executing a flowgraph multiple times from Python

[Nathan Van Ymeren]

  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 <martijn_vdijke@hotmail.com>:

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 <discuss-gnuradio-bounces+martijn_vdijke=hotmail.com@gnu.org> namens Jeff Long <willcode4@gmail.com>
Verzonden: vrijdag 20 augustus 2021 21:52
Aan: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
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 <martijn_vdijke@hotmail.com> 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