Return blocks execution_control from receiving interaction

[simnaut]

Hello!

In TrickHLA/Manager.cpp this return;:

TrickHLA/source/TrickHLA/Manager.cpp

Line 2494 in e2d0918

return;

ends up blocking

TrickHLA/source/TrickHLA/Manager.cpp

Lines 2498 to 2503 in e2d0918

	// Let ExectionControl receive any interactions.
	execution_control->receive_interaction( theInteraction,
	theParameterValues,
	theUserSuppliedTag,
	theTime,
	received_as_TSO );

I am hoping to use the execution_control.receive_interaction() to call my user-defined interaction handler receive_interaction(). Also if there is a better way to do that please let me know.

[dandexter]

It should be that the ExCO interaction handler will not be in the array of Interactions that the user defines. The code will search the user interactions first and if no match is found will try the ExecutionControl, which is what the code should be doing.

Are you wanting to handle ExCO specific interactions from the ExecutionControl or do you want to handle interactions in general?

[simnaut]

I have a "Freeze at a received CTE time" interaction and a "Run at a received CTE time" interaction that I've put in to the ExecutionControl (I put their interactionhandler and interaction objects as members in the ExecutionControl class and then put their receive_interaction method calls in the ExecutionControl receive_interaction method). It sounds like perhaps I shouldn't mix and match implementing interactions in the ExecutionControl and the input.py?

[dandexter]

I would suggest looking at the SpaceFOM::ExecutionControl class on how the Mode Transition Request (MTR) interaction (i.e. mtr_interaction and mtr_interaction_handler) is used in the class.

The design idea is to create your own ExecutionControl class, if it is not already one of the existing SpaceFOM, TrickHLA, or IMSim schemes, with as many interaction and interaction-handlers to suite your needs. When the ExectiionControl::receive_interaction() function is called you will need to determine which of your interactions matches the provided HLA InteractionHandle then delegate the receive_ interaction() function call to that one.

[simnaut]

I have an ExecutionControl::receive_interaction() function that does much of the same as what the SpaceFOM::ExecutionControl::receive_interaction() method does (delegates the receiving of interactions to respective handler receive_interaction() functions) but my ExecutionControl::receive_interaction() function never gets called because of this return:

TrickHLA/source/TrickHLA/Manager.cpp

Line 2494 in e2d0918

return;

I currently have this return commented out in our mirror to get it working for the mean time. I suspect this could be a bug since I would like to define these execution level interactions in the ExCO while still letting users make sim-level interactions via input.py.

[dandexter]

I've spent some time reviewing the code and the TrickHLA design. The intent of the design is to limit one HLA Interaction to just one TrickHLA Interaction and corresponding interaction handler. There were some missing checks for duplicate interaction class names that I have added to the develop branch.

Also, user interactions specified in the TrickHLA Interaction array are buffered and then only processed with the manager.process_interactions() scheduled job is called on the Trick main thread to ensure data coherency.

Interaction defined and used within the ExecutionControl class are not buffered but processed imeduastly because we need to handle the case where a shutdown or other action needs to be taken. Because a federate may be in a spin-lock waiting and also checking for a command to shutdown, it is possible to be in deadlock (i.e. misbehaving federate not advancing time, sync-point not achieved, broken blocking I/O from a federate resigning, etc) and the job to process interactions never called. Because Execution Control needs to be able to correctly indicate things like shutdown even in deadlock the interations are processed immediately and there is no expectation of data coherency.

By commenting out the return statement that would imply you have the same interaction as both a users interaction and an interaction for Execution Control.

Having the same interaction be treated as both a user interaction that ensures data coherency and as an ExecutionControl interaction seems to be in conflict.

It would be good if we could have a conversation over Teams about your design and if the TrickHLA restriction on a one-to-one interaction class to TrickHLA interaction handler makes sense for your design or if it makes sense to make a TrickHLA change. I think with a better understanding of what you are doing may result in either a TrickHLA change or a better design pattern for you implement ExecutionControl interactions.

[simnaut]

Hey Dan, that sounds good to me- I'll email you and I would definitely appreciate any review and guidance.

[HussainAther]

It sounds like the distinction between user-defined and ExecutionControl-level interactions is critical for ensuring reliable behavior, especially under edge-case conditions like deadlocks. Given that, it makes sense why interactions handled by ExecutionControl need to be processed immediately and outside the buffering mechanism.

That said, the design limitation of one interaction per handler (user or ExCO, not both) is a good constraint to document more explicitly .... it’s easy to assume dual registration would "just work." I wonder if a runtime warning or error when an interaction is bound in both places could help users catch this misconfiguration early?

Appreciate your offer for a deeper discussion, it’s great to see this kind of collaborative review around extensibility vs. core system integrity.

[dandexter]

I agree we need updated and better documentation.

I'm open to a discussion on understanding the need to have the same interaction support both user interactions and execution control.

I have added code to check that an Interaction is not used for both a user interaction and execution control. Basically, it checks for duplicate interactions for the same FOM class name.