Optional Components

GPI-Space now supports disabling some components at configuration time to reduce the dependencies needed as well as build time. The following options can be given to CMake with either =OFF or =ON appended:

  • -DGSPC_WITH_MONITOR_APP: The gspc-monitor (also known as “gantt”) application for execution monitoring. This component requires Qt5.

‘eureka-group’ is now available as a tag that contains an expression

The attribute eureka-group of the XML tag <module> can only store constant strings. To allow for data dependent eureka groups, the element <eureka-group> has been introduced as an alternative.

The content of the new tag <eureka-group> is interpreted as an expression and evaluated with the evaluation context of the transition, e.g. with all the input tokens are known. The expression shall return a value of type string.

Please choose between the attribute or the tag, it is an error to specify both.

In general prefer the tag over the attribute as the tag is more flexible. Current application code

<module ... eureka-group="value" ...>
</module>

can now be written as

<module ... ...>
  <eureka-group>"value"</eureka-group>
</module>

Note that the meaning of the double quotes ‘”’ has changed in the example: In the former eureka-group="value" they enclose the attribute value, which is a string. Now, in <eureka-group>"value"</eureka-group> the double quotes are interpreted by the expression parser to parse the (same) string.

The possibility to let the eureka group depend on the inputs of a transition is demonstrated by the example code:

<defun>
  <in name="eureka_group" type="string"/>
  <module>
    <eureka-group>${eureka_group}</eureka-group>
  </module>
</defun>

It determines the eureka group by the value of an input port.

String concatenation can be used to combine information into a more complex eureka group:

<defun>
  <in name="eureka_group" type="string"/>
  <in name="eureka_id" type="string"/>
  <module>
    <eureka-group>${eureka_group} + "_" + ${eureka_id}</eureka-group>
  </module>
</defun>

Installed libraries now hide unintended symbols

To avoid implementation details leaking into user code, GPI-Space’s libraries now no longer export all symbols but instead explicitly export the intended API. Only symbols marked GSPC_DLLEXPORT in the headers are part of the API and other symbols may vanish or change without notice.

This implies that applications might break due to relying on symbols that weren’t intended to be used. This might also be the case when using intended API but linking the wrong library. It might also happen that due to GPI-Space’s dependencies linking a previously missing third-party dependency is now missing.

If an application fails to link with undefined symbols after updating to this version, check whether these symbols came from GPI-Space before. If that’s the case, check

  • whether the correct library is linked
  • whether all third-party dependencies are linked and not relied upon GPI-Space to be provided
  • whether the symbol used is actually part of the public GPI-Space API

The first two cases can be resolved by changing the libraries linked to include the correct dependencies. In the latter case, a sibling function might be part of the API and should be used instead. If there is no such sibling function, contact GPI-Space support to discuss whether it should be added to the API.

[API CHANGE] gspc::worker_description hides its implementation

The structure gspc::worker_description now hides its implementation in order to allow for future changes.

Applications that access the internal information must now store it by themselves.

Also applications can not copy gspc::worker_descriptions any longer but only move them. To adapt to this a current application code of the form

gspc::worker_description const description {args...};

drts.add_worker ({description}, ...);

must now be written as

std::vector<gspc::worker_description> descriptions;
descriptions.emplace_back {args...};
drts.add_worker (descriptions, ...);

CMake Utility Restructuring

GPISpace’s CMake utilities underwent some restructuring as a step towards modernizing the build infrastructure and the ongoing modularization of GPISpace. It is now organized as a standalone project (util-cmake) including install targets and a find package config file. In addition, the directory structure of the scripts was modified to prepend a namespace directory to better reflect the origin of the scripts.

  • util-cmake enforces the usage of a compatible cmake minimum version (currently 3.13). Parent projects will throw a fatal error if they don’t set an appropriate CMake version with cmake_minimum_required before adding util-cmake.
  • All CMake utility scripts need to have the namespace util-cmake/ prepended to them (e.g. include (add_macros) => include (util-cmake/add_macros))
  • The add_unit_test function is no longer part of add_macros.cmake, but resides now in script of its own add_unit_test.cmake.
  • The bundle.sh script should no longer be accessed using a hard-coded path. Instead, util-cmake exposes a variable called util_cmake_bundle_sh populated with the correct absolute path.
  • util-cmake can now be installed if required. By default, the installation is deactivated.

GPISpace CMake Minimum Version Enforcement

Same as util-cmake, GPISpace’s package config file now enforces the usage of a required minimum CMake version (currently 3.13). Applications failing to use at least that version will fail with a fatal error during configuration time.

Fixes

  • Removed methods marked INDICATES_A_RACE from production code.
  • Respect TESTING_RIF_STRATEGY and TESTING_RIF_STRATEGY_PARAMETERS in all tests.
  • Fixed bug related to the thread-safe creation of SSL contexts.
  • Improved documentation: added documentation for the Eureka feature and for creating topology descriptions.

Miscellaneous

  • Applications that link pnetc generated libraries can now link GPISpace::APIGuard instead of defining WE_GUARD_SYMBOL themselves.
  • Removed the attribute children_allowed from workers. The agent can have only terminal components as workers now.
  • Made the worker manager a component that belongs only to the scheduler, forbidding the direct interaction between agent and worker manager. The agent is now just talking to the scheduler, which is the only one who may access the worker manager, in a thread-safe way.
  • Moved functionality proper to scheduling from the worker manager to the scheduler side.