Master update hook vs callback queue

[psoetens]

This PR is supposed to fix #70 in a similar, but improved way
as the original proposal (I'm not going to repeat the bug description here).

There are two diagrams that explain the new behavior (made using Inkscape), which you should look at before trying to understand the code.

The main introduction is the addition of RunnableInterface::work( WorkReason )
and ActivityInterface::timeout() . This allows us to inform the runnable
interface of the reason why it is being executed: because of a TimeOut,
a Trigger, or IO ready. Depending on the reason, the RunnableInterface
subclass can choose to do something different. The ExecutionEngine uses this
to distinguish between message bookkeeping (Triggers) and real work to do
in updateHook ( TimeOut and IOReady ).

In addition, when a TaskContext is Running, an EventPort will call updateHook()
upon newdata or, if a callback is attached, that callback and not updateHook.
This works for periodic and non-periodic *Activity implementations.

Unfortunately, the TaskContext::trigger() will forward to ActivityInterface::timeout()
and the ExecutionEngine will use ActivityInterface::trigger() internally to
do the message/operation bookkeeping. This is confusing in the implementation
side, but keeps the API fully backwards portable.

This PR implements this mechanism for each Activity kind in RTT.

The negative side effects are minimal to none, ie, no existing code should be ported/changed to make use of the improvements in this PR.... unless your code in updateHook() relies on the fact that it is called too much. In Master-Slave setups, the EventPort callbacks are now immediately executed by the master, instead of waiting for a slave::update() call.

If you used ExecutionEngine sharing, patch 42a62e8 removed this capability.

[snrkiwi]

Patch looks good, and diagrams look great! This patch makes an enormous positive difference in our ability to run hardware in hard real-time, and to reason about when things will happen on which cycle. Not having state machine run programs execute multiple times per cycle is a huge win, as is the fixes to the master/slave call operation semantics.

This patch is a huge, positive step forward.

[doudou]

👍 It might break things on our side, but that's really really for a good cause

[jmachowinski]

Looks good.
Hm, I am wondering, can we misuse the timeout thing on the filedescriptor activity to get a behaviour, that is periodic, and FD driven ?

[snrkiwi]

On Apr 22, 2015, at 05:49 AM, jmachowinski notifications@github.com wrote:

Looks good.
Hm, I am wondering, can we misuse the timeout thing on the filedescriptor activity to get a behaviour, that is periodic, and FD driven ?
 
What are you actually trying to achieve here? If you simply want to use the FDA to get a periodic activity, then what's the benefit of that over the standard periodic Activity implementation? The timeout does not actually write to the FD, it simply wakes up the activity.
S

[jmachowinski]

We had the problem, that the task would just stall if no data was coming in on the FD.
In this case we would just enter an exception state.
Ok, I just looked up the API of the FDA. Lets just say we never discovered the timeout
in the past 4 years...

We also had this problem in the reverse direction. If our task is port driven, and we don't get
data. In this case we want to enter an exception state if we did not get data on the ports in X ms.
If I did not miss anything, this patch fixes exactly this issue.

[jmachowinski]

To clarify this, our use case is a task for a motor driver. We want to enter exception, if either
the hardware did not give us an alive for X ms. We also want to enter the exception state (and shutdown the motor) if our controller stalled. For now we always used periodic activities for this,
which delays the processing of the incoming data. And we would like to be FD and Port driven.

[psoetens]

This PR is quite ok, except that in commit f266337 we collate the message queue with the port queue. This is a bad idea because we can have cases that your own port callback is called during a 'peer.foo.call()' in your code, which never happened in 2.8, since in 2.8, port callbacks are processed after all messages are processed.

For merging this into 2.9, we should ammend this patch such that the port queue is re-added, but a processPorts() function is created which then executes all callbacks in that queue, instead of the prepareforupdatehook() function. This cleans up, without changing semantics.

[meyerj]

Merged into toolchain-2.9 again in 71cd9f6.

[meyerj]

Merging into master now. The new behavior is considered stable and has been used in the toolchain-2.9 for years now, with a few iterations. Other pull requests currently targeting toolchain-2.9 heavily depend on this one.