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
