Transitive lifetime dependencies
This MR allows argument dependencies to be calculated transitively. This makes using argument dependencies more usable as it prevents having to declare all dependencies, and lets dependencies be defined naturally one on top of the other.
For instance, the dependencies of a UT datatype were before:
DEVICE_OUTPUT_WITH_DEPENDENCIES(
dev_ut_multi_event_tracks_view_t,
DEPENDENCIES(
dev_ut_hits_view_t,
dev_ut_track_view_t,
dev_ut_tracks_view_t,
dev_velo_tracks_view_t,
dev_ut_track_velo_indices_t,
dev_ut_track_params_t,
dev_ut_track_hits_t,
dev_offsets_ut_tracks_t,
dev_offsets_ut_track_hit_number_t),
whereas now they become simply:
DEVICE_OUTPUT_WITH_DEPENDENCIES(
dev_ut_multi_event_tracks_view_t,
DEPENDENCIES(
dev_ut_tracks_view_t),
Alongside this change, two new datatypes have been created of type Allen::IMultiEventLHCbIDContainer*
, one for the VELO (dev_velo_multi_event_lhcb_id_container_t
) and another one for the UT (dev_ut_multi_event_lhcb_id_container_t
). These datatypes can be used to accept a generic container of (multi-event) tracks, that can be dynamically casted in an algorithm for container-specific functionality.
This MR also allows dependencies to contain INPUT_AGGREGATE
datatypes.
Example
This applies to any output datatype that used the construct DEVICE_OUTPUT_WITH_DEPENDENCIES
. It guarantees that an output's lifetime and all its dependencies remain valid when an algorithm requests the datatype, even if the algorithm didn't request the dependencies.
Eg.
Algorithm A produces outputs a, and b. b is marked to depend on a (it relies on some information stored in a, maybe it has a pointer to a). Algorithm B requests b.
Algorithm B also requires a to be valid, therefore the lifetime of a has to be extended to all the uses of b.
Allen already allowed that feature with DEVICE_OUTPUT_WITH_DEPENDENCIES
. However, now it also supports transitive dependencies (c requires b, which in turn requires a).