Confused about physical action.

[stustd]

I'm slightly confused about the use of physical action. Where the documentation says
"""
Moreover, for a physical action, unlike a logical action, the schedule function can only be invoked from outside of any reaction (asynchronously), e.g. from an interrupt service routine or callback function.
"""
both the C examples, ManualDelayedReaction.lf and SlowingClockPhysical.lf schedule the physical actions (act and a, respectively) from within a reaction.... How should I interpret this?

My focus is to learn how to use physical actions for both callbacks and sensor polling. Thanks.

[edwardalee]

I just fixed the documentation to read:

Moreover, for a physical action, unlike a logical action, the schedule function can be invoked from outside of any reaction (asynchronously), e.g. from an interrupt service routine or callback function.

[cmnrd]

Apparently the wording in the documentation is misleading (if not wrong). The main difference between logical and physical actions is the timeline which they create events respective to. Scheduling a logical action will always create an event based on the current tag (logical timeline). If the given delay is 0, this will be the current tag plus one microstep, otherwise it is the current tag plus the given delay. Scheduling a physical action will create an event based on the current physical time. If the given delay is 0, the tag of this event will be equal to the current physical time, otherwise it is the current physical time plus the given delay.

Physical actions are particularly useful to deal with asynchronous inputs and are normally scheduled from an external context. This is illustrated for instance in the ReflexGame examples. However, in principle physical actions can also be scheduled from a reaction. If that makes sense, however, depends on the use-case.

You mention callbacks and polling. For callbacks physical actions should be the way to go. For polling, however, probably a timer or logical action is better, because they would give you fixed intervals in between two readings.

[stustd]

"""
Physical actions are particularly useful to deal with asynchronous inputs and are normally scheduled from an external context.
"""
In my (C++) application, I have two synchronous systems communicating asynchronously to each other. I was considering putting ZMQ in between as the async layer. Alternatively, with async physical action I can also just poll an event buffer with a timer or logical action. This would make ZMQ completely unnecessary... Your ideas on this are welcome!

[cmnrd]

It is hard to give advice without knowing the precise use-case. In general, physical actions would be your tool of choice if you receive asynchronous requests and want to react to it in some callback or from a polling thread. For callbacks, there is a good TypeScript example here, that schedules a physical action whenever there is a http request. The ReflexGame is an example of a polling thread that runs concurrently to the LF application.

Since you say you have two synchronous systems interacting, I wonder how the communication between the systems is designed. Are the two systems written in LF? Should timestamps be preserved when communicating? Or is order only relevant within one of your systems, but not between the systems?

I would also like to point out that we have support for federated executions, where reactors may communicate over the network. Essentially, this creates a synchronous distributed system. However, federation is not supported by the C++ target (yet).

[stustd]

"""
Since you say you have two synchronous systems interacting, I wonder how the communication between the systems is designed. Are the two systems written in LF? Should timestamps be preserved when communicating? Or is order only relevant within one of your systems, but not between the systems?
"""
I'm planning to write directly in C++ (using the reactor-cpp library). Timestamped order is (semi-?) relevant in the communication between the systems -- it's async intercom on a single machine so I assume/hope that can be managed...; do look forward to federation support in C++ implementation though. Thanks for your thoughts!