Jens Georg authored 2 years ago and Martin Christoph Hierholzer committed 2 years ago

 - ApplicationModule can only be owned by ModuleGroup

Jens Georg authored 2 years ago and Martin Christoph Hierholzer committed 2 years ago

Move everything inside TestableMode and add decorator helper functions
to TestableMode

Jens Georg authored 2 years ago and Martin Christoph Hierholzer committed 2 years ago

While at it, fix linter issues in ModuleGroup as well

Modernise interface of status monitors and add tests of initial value propagation and data validity propagation (#8279). Improve code formating/readability.

* fix code formatting

* enable coding style test

it was anyway dysfunctional and mainly slightly reducing performance.

The VoidAccessor comes along with the convenience classes VoidInput and VoidOutput,
and the TestFacility function getVoid()

Introduce StatusWithMessage and StatusWithMessageReader which handle this.
It is used in DeviceModule error reporting.
This is a preparation in order that we can report errors consistently to DOOCS, in DoocsAdapter

make StatusAggregator use StatusWithMessage

it should output always status code + string
on the input side, connects to either status or status + string
corresponding string input is found automatically
NOTE: DeviceModule API change, the status output variables are
renamed from (status, message) to (status, status_message)!

update testing of DeviceModule outputs

because of API change of DeviceModule  (renamed message ->
status_message)

fix crash and improve message and test

- fix crash due to incorrect handling of cast to Derived
- improve message output
- make existing tests pass
- add test for status message of StatusAggregator

move StatusWithMessageReaderBase and Status def to ControlSystemAdapter

since it is required from ApplicationCore as well as from the adapters

Simply add timeout to acquiring the testable mode lock and print an error message with the last thread which successfully obtained the thread. Finally throw an exception to help debugging.

It can be static and it may make sense to use it outside modules. The implementation should probably move to a Application member function to make it easier to reach from non-module code.

to check whether stepApplication() can execute...

This was a left-over from times when no proper initial value propagation
and exception handling was implemented in ApplicationCore. Waiting until
the backends are open is anyway not sufficient, since the DeviceModule
needs to finish the recovery procedure. If any test would still rely on
this (anti-)feature, it would be subject to race conditions.

The wait is removed because it prevents important tests for the
exception handling specification. In particular, tests which
intentionally break devices during startup of the application would not
be implementable.

When writing special modules (e.g. the MicroDAQ module) it may be necessary to both override and call this function explicitly.

This generates graphviz code to visualise the connections between modules

Require e.g. when needing to report an exception programmatically

The previous implementation using the mutex had two issues:

1. The mutex was locked in a different thread than unlocked (DeviceModule constructor vs. handleException() thread). This results in undefined behaviour.
2. The boost::shared_mutex::lock_shared() function is not an interruption point, so applications did not terminate while waiting for initial values. (boost::latch::wait() is an interruption point.)

Just use enableDebugDataLoss() to enable debug output.