Tags: AliceO2Group/QualityControl
Tags
Update instructions for local build on an FLP suite setup (#2672) Based on recent experiences with the FOCAL setup.
Update instructions for local build on an FLP suite setup (#2672) Based on recent experiences with the FOCAL setup.
Tagging QualityControl version async-DataRec-2026-v7
Tagging QualityControl version async-2026-PbPb-apass1-v5
Tagging QualityControl version async-2026-PbPb-apass1-v4
[QC-1346] Scaffolding to share common code among QC data processors (#… …2660) * QC-1346 Scaffolding to share common code among QC data processors Actor is a template base class for all QC Data Processors. It is supposed to bring their commonalities together, such as: service initialization, Data Processing Layer adoption, retrieving configuration and runtime parameters, interactions with controlling entities (DPL driver, AliECS, ODC). The design is based on CRTP (see the web for explanation), which allows us to: - avoid code repetition in implementing aforementioned commonalities - optionally perform certain actions depending on traits of an Actor specialization. CRTP, in contrast to dynamic inheritance, is also advertised to avoid performance impact due to vtable lookups. It is certainly a nice bonus in our case, but it was not the main motivation for CRTP-based approach. To allow for compile-time customization of centralized Actor features, we require each concrete Actor to implement an ActorTraits structure with certain parameters which is enforced with ValidActorTraits concept. The traits are separated from the main Actor class to improve readability and allow for shorter compilation times by allowing many helper functions avoid including Actor.h and a corresponding actor specialization. For additional savings on compilation time and clutter in code, we validate ActorTraits specializations with a concept only in Actor, but this could be revisited if proven wrong. This commit paves the path for refactoring existing QC data processors as Actor specializations/children. * keep clang happy even though I don't believe it's right Clang complains that: ``` SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx /Volumes/build/alice-ci-workdir/qualitycontrol-o2/sw/SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx:97:5: error: call to consteval function 'o2::quality_control::core::UnrequestedAccessActor::assertNoAccessToServices<o2::quality_control::core::UnrequestedAccessActor>' is not a constant expression 97 | assertNoAccessToServices<UnrequestedAccessActor>(); | ^ /Volumes/build/alice-ci-workdir/qualitycontrol-o2/sw/SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx:97:5: note: implicit use of 'this' pointer is only allowed within the evaluation of a call to a 'constexpr' member function 1 error generated. ``` GCC is fine and is able to process it as a consteval expression. Let's keep both happy by using constexpr, given it's just a test. * Assume "resilient" for critical data processors with uncertain upstream * Move correct inheritance check to happen after the type is fully known to make clang happy again * Get rif of the protection against faulty inheritance of actors The disadvantage is that then the child can access and modify parent's private members, such as mActivity, and cause rather unpredictable behaviours. I don't think it's worth having a protection which in the end would cause a different kind of bugs. * add missing file header
[QC-1346] Scaffolding to share common code among QC data processors (#… …2660) * QC-1346 Scaffolding to share common code among QC data processors Actor is a template base class for all QC Data Processors. It is supposed to bring their commonalities together, such as: service initialization, Data Processing Layer adoption, retrieving configuration and runtime parameters, interactions with controlling entities (DPL driver, AliECS, ODC). The design is based on CRTP (see the web for explanation), which allows us to: - avoid code repetition in implementing aforementioned commonalities - optionally perform certain actions depending on traits of an Actor specialization. CRTP, in contrast to dynamic inheritance, is also advertised to avoid performance impact due to vtable lookups. It is certainly a nice bonus in our case, but it was not the main motivation for CRTP-based approach. To allow for compile-time customization of centralized Actor features, we require each concrete Actor to implement an ActorTraits structure with certain parameters which is enforced with ValidActorTraits concept. The traits are separated from the main Actor class to improve readability and allow for shorter compilation times by allowing many helper functions avoid including Actor.h and a corresponding actor specialization. For additional savings on compilation time and clutter in code, we validate ActorTraits specializations with a concept only in Actor, but this could be revisited if proven wrong. This commit paves the path for refactoring existing QC data processors as Actor specializations/children. * keep clang happy even though I don't believe it's right Clang complains that: ``` SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx /Volumes/build/alice-ci-workdir/qualitycontrol-o2/sw/SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx:97:5: error: call to consteval function 'o2::quality_control::core::UnrequestedAccessActor::assertNoAccessToServices<o2::quality_control::core::UnrequestedAccessActor>' is not a constant expression 97 | assertNoAccessToServices<UnrequestedAccessActor>(); | ^ /Volumes/build/alice-ci-workdir/qualitycontrol-o2/sw/SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx:97:5: note: implicit use of 'this' pointer is only allowed within the evaluation of a call to a 'constexpr' member function 1 error generated. ``` GCC is fine and is able to process it as a consteval expression. Let's keep both happy by using constexpr, given it's just a test. * Assume "resilient" for critical data processors with uncertain upstream * Move correct inheritance check to happen after the type is fully known to make clang happy again * Get rif of the protection against faulty inheritance of actors The disadvantage is that then the child can access and modify parent's private members, such as mActivity, and cause rather unpredictable behaviours. I don't think it's worth having a protection which in the end would cause a different kind of bugs. * add missing file header
[QC-1346] Scaffolding to share common code among QC data processors (#… …2660) * QC-1346 Scaffolding to share common code among QC data processors Actor is a template base class for all QC Data Processors. It is supposed to bring their commonalities together, such as: service initialization, Data Processing Layer adoption, retrieving configuration and runtime parameters, interactions with controlling entities (DPL driver, AliECS, ODC). The design is based on CRTP (see the web for explanation), which allows us to: - avoid code repetition in implementing aforementioned commonalities - optionally perform certain actions depending on traits of an Actor specialization. CRTP, in contrast to dynamic inheritance, is also advertised to avoid performance impact due to vtable lookups. It is certainly a nice bonus in our case, but it was not the main motivation for CRTP-based approach. To allow for compile-time customization of centralized Actor features, we require each concrete Actor to implement an ActorTraits structure with certain parameters which is enforced with ValidActorTraits concept. The traits are separated from the main Actor class to improve readability and allow for shorter compilation times by allowing many helper functions avoid including Actor.h and a corresponding actor specialization. For additional savings on compilation time and clutter in code, we validate ActorTraits specializations with a concept only in Actor, but this could be revisited if proven wrong. This commit paves the path for refactoring existing QC data processors as Actor specializations/children. * keep clang happy even though I don't believe it's right Clang complains that: ``` SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx /Volumes/build/alice-ci-workdir/qualitycontrol-o2/sw/SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx:97:5: error: call to consteval function 'o2::quality_control::core::UnrequestedAccessActor::assertNoAccessToServices<o2::quality_control::core::UnrequestedAccessActor>' is not a constant expression 97 | assertNoAccessToServices<UnrequestedAccessActor>(); | ^ /Volumes/build/alice-ci-workdir/qualitycontrol-o2/sw/SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx:97:5: note: implicit use of 'this' pointer is only allowed within the evaluation of a call to a 'constexpr' member function 1 error generated. ``` GCC is fine and is able to process it as a consteval expression. Let's keep both happy by using constexpr, given it's just a test. * Assume "resilient" for critical data processors with uncertain upstream * Move correct inheritance check to happen after the type is fully known to make clang happy again * Get rif of the protection against faulty inheritance of actors The disadvantage is that then the child can access and modify parent's private members, such as mActivity, and cause rather unpredictable behaviours. I don't think it's worth having a protection which in the end would cause a different kind of bugs. * add missing file header
[QC-1346] Scaffolding to share common code among QC data processors (#… …2660) * QC-1346 Scaffolding to share common code among QC data processors Actor is a template base class for all QC Data Processors. It is supposed to bring their commonalities together, such as: service initialization, Data Processing Layer adoption, retrieving configuration and runtime parameters, interactions with controlling entities (DPL driver, AliECS, ODC). The design is based on CRTP (see the web for explanation), which allows us to: - avoid code repetition in implementing aforementioned commonalities - optionally perform certain actions depending on traits of an Actor specialization. CRTP, in contrast to dynamic inheritance, is also advertised to avoid performance impact due to vtable lookups. It is certainly a nice bonus in our case, but it was not the main motivation for CRTP-based approach. To allow for compile-time customization of centralized Actor features, we require each concrete Actor to implement an ActorTraits structure with certain parameters which is enforced with ValidActorTraits concept. The traits are separated from the main Actor class to improve readability and allow for shorter compilation times by allowing many helper functions avoid including Actor.h and a corresponding actor specialization. For additional savings on compilation time and clutter in code, we validate ActorTraits specializations with a concept only in Actor, but this could be revisited if proven wrong. This commit paves the path for refactoring existing QC data processors as Actor specializations/children. * keep clang happy even though I don't believe it's right Clang complains that: ``` SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx /Volumes/build/alice-ci-workdir/qualitycontrol-o2/sw/SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx:97:5: error: call to consteval function 'o2::quality_control::core::UnrequestedAccessActor::assertNoAccessToServices<o2::quality_control::core::UnrequestedAccessActor>' is not a constant expression 97 | assertNoAccessToServices<UnrequestedAccessActor>(); | ^ /Volumes/build/alice-ci-workdir/qualitycontrol-o2/sw/SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx:97:5: note: implicit use of 'this' pointer is only allowed within the evaluation of a call to a 'constexpr' member function 1 error generated. ``` GCC is fine and is able to process it as a consteval expression. Let's keep both happy by using constexpr, given it's just a test. * Assume "resilient" for critical data processors with uncertain upstream * Move correct inheritance check to happen after the type is fully known to make clang happy again * Get rif of the protection against faulty inheritance of actors The disadvantage is that then the child can access and modify parent's private members, such as mActivity, and cause rather unpredictable behaviours. I don't think it's worth having a protection which in the end would cause a different kind of bugs. * add missing file header
[QC-1346] Scaffolding to share common code among QC data processors (#… …2660) * QC-1346 Scaffolding to share common code among QC data processors Actor is a template base class for all QC Data Processors. It is supposed to bring their commonalities together, such as: service initialization, Data Processing Layer adoption, retrieving configuration and runtime parameters, interactions with controlling entities (DPL driver, AliECS, ODC). The design is based on CRTP (see the web for explanation), which allows us to: - avoid code repetition in implementing aforementioned commonalities - optionally perform certain actions depending on traits of an Actor specialization. CRTP, in contrast to dynamic inheritance, is also advertised to avoid performance impact due to vtable lookups. It is certainly a nice bonus in our case, but it was not the main motivation for CRTP-based approach. To allow for compile-time customization of centralized Actor features, we require each concrete Actor to implement an ActorTraits structure with certain parameters which is enforced with ValidActorTraits concept. The traits are separated from the main Actor class to improve readability and allow for shorter compilation times by allowing many helper functions avoid including Actor.h and a corresponding actor specialization. For additional savings on compilation time and clutter in code, we validate ActorTraits specializations with a concept only in Actor, but this could be revisited if proven wrong. This commit paves the path for refactoring existing QC data processors as Actor specializations/children. * keep clang happy even though I don't believe it's right Clang complains that: ``` SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx /Volumes/build/alice-ci-workdir/qualitycontrol-o2/sw/SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx:97:5: error: call to consteval function 'o2::quality_control::core::UnrequestedAccessActor::assertNoAccessToServices<o2::quality_control::core::UnrequestedAccessActor>' is not a constant expression 97 | assertNoAccessToServices<UnrequestedAccessActor>(); | ^ /Volumes/build/alice-ci-workdir/qualitycontrol-o2/sw/SOURCES/QualityControl/2660/0/Framework/test/testActor.cxx:97:5: note: implicit use of 'this' pointer is only allowed within the evaluation of a call to a 'constexpr' member function 1 error generated. ``` GCC is fine and is able to process it as a consteval expression. Let's keep both happy by using constexpr, given it's just a test. * Assume "resilient" for critical data processors with uncertain upstream * Move correct inheritance check to happen after the type is fully known to make clang happy again * Get rif of the protection against faulty inheritance of actors The disadvantage is that then the child can access and modify parent's private members, such as mActivity, and cause rather unpredictable behaviours. I don't think it's worth having a protection which in the end would cause a different kind of bugs. * add missing file header
PreviousNext