| Re: [4diac-dev] Confusion regarding communication architecture |
Thank you very much for the detailed explanation!
The thing that confused me the most was that I assumend interruptCommFB automatically interrupted the executor and started the event handling. That's obviously not the case.
Today I dug deeper into Forte core (CCommFB and CCommLayer) which further explained how things work. And I also realized there is a plenty of Doxygen documentation hidden in the code so I generated it. :)
But I didn't yet get very deep into startNewEventChain. The explanation that you gave me, along with the coding pattern will be extremely helpful in the upcoming parts of my project.
I'm still very curious about the scenario when Handler/CommLayer need to generate multiple events at once. I.e. there were two requests, and server sent both responses in one frame. Or in more generic terms, a second response arrives even before the executor called the first processInterrupt. From what I've seen most (if not all) protocol implementations won't handle that properly.
From what I gathered interruptCommFB can be called during processInterrupt, and by doing that it will be registered immediately for the next cycle. In theory that could be used to pop one by one response from an incoming queue. But I would need to be careful to prevent an asynchronous thread (the data source) from calling interruptCommFB until it is stopped from being called from processInterrupt. But what about startNewEventChain? Does it need to be called along with each next interruptCommFB (while the output queue is not empty)?
Am I even going in the right direction? Should I ditch that idea
and implement some other two way handshake with the handler (which
has its own thread)?
Hi Davor, the part with the startNewEventChain (yes the name changed) is one of the more complicated and also most dangerous parts of 4diac FORTE. The reason for that is that it is used to inform a resource/FB that some external event occurred that this specific FB needs to handle. External events are from the 4diac FORTE perspective anything that is coming from the outside (e.g., network message received, interrupt of an IO) that needs in the end some attention in an FB or where later an output event of an FB (typically IND) needs to be triggered. As you may have seen such external event sources are in 4diac FORTE managed by classes inheriting from the CExternalEventManager class. Typically there is only one instance of this class and each instance is managing one external event source. Typically an external event manager has some kind of list or table with all FBs expecting to receive some trigger from this external event source. If you are following our communication architecture this could also be a list of communication layers. So the normal operation for communication layers is such that the external event handler would be notified by the reception of a message. It would search for the right layer and forward the data to it. The layer can do what is needed to process it, and if needed invoke the interruptCommFB. Which you say is nicely explained. Now we come to the part that most probably interests you most: When the commlayer is returning to the handler it should tell the handler if all data has arrived and the FB should be notified about it. Currently most layers are doing this by returning a value that is != e_Nothing. If that is the case the external event handler needs to inform the associated FB. This is done by invoking the startNewEventChain method provided by the base class of the external event manager: CExternalEventManager. This will trigger a rather complicated process of inserting events int queues, activating threads, and in the end activating the CCommFB with an external event. Per default the commFB should now do everything that is necessary to call your layer and that you can apply the data received to the outputs of the commfb. It will also send the appropriate output events. To make the whole thing short. In the end you need in your external event handler a piece of code that is invoking the recv method of your layer and if the return is not e_Nothing invoke start new event chain: if(forte::com_infra::e_Nothing != layer->recvData(pPayLoad, payLoadSize)){ startNewEventChain(layer->getCommFB()); } The rest should be handled by the infrastructure of 4diac FORTE. I hope this clarifies a bit and helps you. Cheers, Alois On Wed, 2022-04-20 at 12:24 +0200, Davor Cihlar wrote:Hi! I'm implementing PostgreSQL support for Forte and I'm confused about some parts of the architecture. If someone have some time to help me understand it I would very much appreciate it. On the web interruptCommFB is perfectly explained. But startEventChain (or is it startNewEventChain now?) isn't, so I'm not sure what its purpose is. Also from the existing sources (xquery, OPC, and some others) it looks like there is always some kind of queue (and always implemented from scratch which is not ideal) for commands sent to a handler. I.e. "go and fetch me some data". But there is no queue of any kind for data that is going towards outputs of FBs. This doesn't look good if some process makes multiple data requests and Handler tries to send all responses to FB ouputs immediately. Or am I missing something big? P.S.: I wanted to post this on the forum, but unfortunately I managed to lock my account and I don't know when the lock will time out. _______________________________________________ 4diac-dev mailing list 4diac-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev_______________________________________________ 4diac-dev mailing list 4diac-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev