[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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)?
On 4/20/22 21:53, Alois Zoitl wrote:
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