Avoiding circular dependency with signals/slots
-
Hi and welcome to devnet,
You could take a look at QNetworkAccessManager, your architecture description makes it look like a usefully inspiration.
-
Hi and welcome to devnet,
You could take a look at QNetworkAccessManager, your architecture description makes it look like a usefully inspiration.
-
Two ways:
1, same signals are sent to all nodes. These signals, however, have embedded Node id info in them. Parse them and ignore the signals which are not related. Simple protocol thing.
2. send different signals to different nodes.
I will go with the first one. -
Two ways:
1, same signals are sent to all nodes. These signals, however, have embedded Node id info in them. Parse them and ignore the signals which are not related. Simple protocol thing.
2. send different signals to different nodes.
I will go with the first one. -
@JoeCFD 1. is what I proposed in the question, but worried that it would be inefficient.
Not sure how 2. would work as the "Nodes" are generated dynamically, unless there's also a way to dynamically create signals? Thanks -
@SGaist Thanks for your response. Could you elaborate please? I'm not sure how QNetworkAccessManager might solve my problem.
@ECEC said in Avoiding circular dependency with signals/slots:
@SGaist Thanks for your response. Could you elaborate please? I'm not sure how QNetworkAccessManager might solve my problem.
I meant from an architecture point of view.
With QNAM you can either connect your QNAM directly and manage things with it concerning the replies or you use the QNetworkReply returned by the operation you want to execute and use its signals and slots.
-
@ECEC said in Avoiding circular dependency with signals/slots:
@SGaist Thanks for your response. Could you elaborate please? I'm not sure how QNetworkAccessManager might solve my problem.
I meant from an architecture point of view.
With QNAM you can either connect your QNAM directly and manage things with it concerning the replies or you use the QNetworkReply returned by the operation you want to execute and use its signals and slots.
-
Your ProtocolManager could return something similar to a reply that could then be connected by the Node to a lambda or a slot to do further processing of the answer.
Therefor, your ProtocolManager would not have to care about the Node objects.
-
Your ProtocolManager could return something similar to a reply that could then be connected by the Node to a lambda or a slot to do further processing of the answer.
Therefor, your ProtocolManager would not have to care about the Node objects.
@SGaist Ahhh, I think I see what you mean. So when the Nodes make a command request to the ProtocolManager, it returns a pointer to some sort of Reply object which the ProtocolManager populates when data for that Node is available. The Reply object then emits a signal which connects to a slot in Node. As requests are made frequently (10/sec) and the responses are short, I wonder whether it might make sense to have just one Reply object per Node instead of generating a new one per command request. What do you think, and is the above what you had in mind? Cheers
-
@SGaist Ahhh, I think I see what you mean. So when the Nodes make a command request to the ProtocolManager, it returns a pointer to some sort of Reply object which the ProtocolManager populates when data for that Node is available. The Reply object then emits a signal which connects to a slot in Node. As requests are made frequently (10/sec) and the responses are short, I wonder whether it might make sense to have just one Reply object per Node instead of generating a new one per command request. What do you think, and is the above what you had in mind? Cheers
Yes that's that.
I would first get it to work and then benchmark the simple implementation. If you see performance issue then start optimizing.
-
Yes that's that.
I would first get it to work and then benchmark the simple implementation. If you see performance issue then start optimizing.
-
If you queue the request, it should not.
As already suggested, you should take a look at the implementation of QNAM. You make a request, get a reply object and there's no "speed" issue with it.
