Deadline monitoring CPP API #48

pawelrutkaq · 2026-01-22T14:02:20Z

UT will be added after the first review round
Deadlines not yet allocated in the right place

Closes #14

github-actions · 2026-01-22T14:03:39Z

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.4.2) and connecting to it...
INFO: Invocation ID: 0cad9d03-5f55-4157-9a59-c81c9bc2edfe
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
DEBUG: Rule 'rust_qnx8_toolchain+' indicated that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-eQOopREOYCL5vtTb6c1cwZrql4GVrJ1FqgxarQRe1xs="
DEBUG: Repository rust_qnx8_toolchain+ instantiated at:
  <builtin>: in <toplevel>
Repository rule http_archive defined at:
  /home/runner/.bazel/external/bazel_tools/tools/build_defs/repo/http.bzl:431:31: in <toplevel>
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 2 packages loaded
Loading: 2 packages loaded
    currently loading: 
Loading: 2 packages loaded
    currently loading: 
Loading: 2 packages loaded
    currently loading: 
Analyzing: target //:license-check (3 packages loaded, 0 targets configured)
Analyzing: target //:license-check (3 packages loaded, 0 targets configured)

Analyzing: target //:license-check (37 packages loaded, 10 targets configured)

Analyzing: target //:license-check (89 packages loaded, 10 targets configured)

Analyzing: target //:license-check (131 packages loaded, 1525 targets configured)

Analyzing: target //:license-check (148 packages loaded, 4807 targets configured)

Analyzing: target //:license-check (154 packages loaded, 7409 targets configured)

Analyzing: target //:license-check (154 packages loaded, 7412 targets configured)

Analyzing: target //:license-check (154 packages loaded, 7412 targets configured)

INFO: Analyzed target //:license-check (162 packages loaded, 13697 targets configured).
[1 / 1] no actions running
INFO: Found 1 target...
Target //:license.check.license_check up-to-date:
  bazel-bin/license.check.license_check
  bazel-bin/license.check.license_check.jar
INFO: Elapsed time: 25.859s, Critical Path: 0.47s
INFO: 13 processes: 4 disk cache hit, 9 internal.
INFO: Build completed successfully, 13 total actions
INFO: Running command line: bazel-bin/license.check.license_check ./formatted.txt <args omitted>
usage: org.eclipse.dash.licenses.cli.Main [-batch <int>] [-cd <url>]
       [-confidence <int>] [-ef <url>] [-excludeSources <sources>] [-help] [-lic
       <url>] [-project <shortname>] [-repo <url>] [-review] [-summary <file>]
       [-timeout <seconds>] [-token <token>]

Copilot

Pull request overview

This PR introduces a C++ FFI (Foreign Function Interface) API for deadline monitoring functionality in the health monitoring library. The changes enable C++ code to interact with the Rust-based deadline monitoring system through a well-defined interface.

Changes:

Added FFI bindings in Rust to expose deadline monitoring functionality to C++
Implemented C++ wrapper classes (HealthMonitor, DeadlineMonitor, Deadline) that interface with the Rust backend
Created build configuration for compiling both Rust static library and C++ library components

Reviewed changes

Copilot reviewed 20 out of 22 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/health_monitoring_lib/src/lib.rs	Added `HealthMonitor` and `HealthMonitorBuilder` structs to manage deadline monitors
src/health_monitoring_lib/src/ffi.rs	New FFI functions for health monitor builder creation, destruction, and deadline monitor management
src/health_monitoring_lib/src/deadline/ffi.rs	New FFI functions for deadline monitor operations including builder, monitor, and deadline lifecycle management
src/health_monitoring_lib/src/deadline/deadline_monitor.rs	Refactored deadline monitoring to support FFI usage with internal helper methods
src/health_monitoring_lib/src/common.rs	Changed `IdentTag` to FFI-compatible representation and added FFI helper utilities
src/health_monitoring_lib/cpp/include/score/hm/health_monitor.h	C++ header defining `HealthMonitor` and `HealthMonitorBuilder` classes
src/health_monitoring_lib/cpp/include/score/hm/deadline/deadline_monitor.h	C++ header defining deadline monitoring classes (`DeadlineMonitor`, `Deadline`, `DeadlineHandle`)
src/health_monitoring_lib/cpp/include/score/hm/common.h	C++ header with common types including `IdentTag`, `TimeRange`, and FFI helpers
src/health_monitoring_lib/cpp/health_monitor.cpp	Implementation of C++ `HealthMonitor` classes
src/health_monitoring_lib/cpp/deadline/deadline_monitor.cpp	Implementation of C++ deadline monitoring classes
src/health_monitoring_lib/cpp/common.cpp	Implementation of `DroppableFFIHandle` utility class
src/health_monitoring_lib/cpp/ffi_helpers.h	Helper function to convert Rust error codes to C++ Error enum
src/health_monitoring_lib/cpp/tests/health_monitor_test.cpp	Basic test demonstrating the C++ API usage
src/health_monitoring_lib/BUILD	Updated build configuration to include Rust static library and C++ library targets

Comments suppressed due to low confidence (1)

src/health_monitoring_lib/src/deadline/ffi.rs:1

Corrected grammar from 'This function is provides' to 'This function is provided'.

use crate::common::ffi::*;

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

src/health_monitoring_lib/cpp/ffi_helpers.h

src/health_monitoring_lib/src/ffi.rs

src/health_monitoring_lib/cpp/include/score/hm/health_monitor.h

src/health_monitoring_lib/cpp/tests/health_monitor_test.cpp

README.md

github-actions · 2026-01-22T14:05:02Z

The created documentation from the pull request is available at: docu-html

pawelrutkaq · 2026-01-22T14:34:18Z

I will fix QNX8 after first review rounds

arkjedrz

Mostly nitpicks, but error handling can definitely be improved.

scripts/generate_cpp_compile_commands.sh

README.md

MODULE.bazel

arkjedrz · 2026-01-22T15:02:14Z

MODULE.bazel

 use_repo(toolchains_qnx, "toolchains_qnx_ifs")

 bazel_dep(name = "score_baselibs_rust", version = "0.0.3")
+bazel_dep(name = "score_baselibs", version = "0.2.2")


Why moved here?

To keep in code deps in single place

arkjedrz · 2026-01-22T15:07:16Z

src/health_monitoring_lib/cpp/include/score/hm/deadline/deadline_monitor.h

+ *
+ * SPDX-License-Identifier: Apache-2.0
+ ********************************************************************************/
+#ifndef SCORE_HM_DEADLINE_DEADLINE_MONITOR_H


Why not #pragma once?

because score ues ifdefs

src/health_monitoring_lib/cpp/tests/health_monitor_test.cpp

src/health_monitoring_lib/rust/deadline/deadline_monitor.rs

src/health_monitoring_lib/cpp/include/score/hm/health_monitor.h

src/health_monitoring_lib/src/lib.rs

src/health_monitoring_lib/cpp/deadline_monitor.cpp

SimonKozik · 2026-01-23T13:35:20Z

.vscode/settings.json

In general I'm not against committing editor config files into repo, but this makes sense if we all use the same editor.

Maybe this file should be on the git ignore list?

some ide shall work out of box, and this IDE is used mostly in score. If someone does not use it, it's no harm. If you have specific settings. So those are shared settings. user settings can always be overwritten/

Like I said, I'm not against having those files in git. But if you want to enforce some style, then maybe you should look at repo hooks.

All this is checked by CI or (formatting etc )? If we don't add this, each user will have to do it manually for VS Code (and figure out how to do it with s-core bazel first).

src/health_monitoring_lib/BUILD

scripts/generate_cpp_compile_commands.sh

SimonKozik · 2026-01-23T14:39:51Z

src/health_monitoring_lib/cpp/deadline_monitor.cpp

+#include "score/hm/deadline/deadline_monitor.h"
+#include "ffi_helpers.h"
+
+extern "C" {


Is there a reason why this C interface is not declared in its own header?

At the moment it is hard to follow this code, but I understand it to work like this:

We have core implementation in Rust.

Then we have Foreign Function Interface (FFI) around that.

Finally we have intended Cpp interface that is linked with FFI library.

I could be wrong above, but if I'm right, I would prefer to have folder and file structure organized around that. That should allow us to see boundaries easier and also should make build files a bit easier.

Please be more specific. Not sure what you mean here but from call site You are correct. I can extract C FFI calls to a separate header but not sure what it would help ;) I keep them isolated in context of where they are used.

Please note that there is not much comments in the code, there is also no description in readme file on the approach taken in this PR.

I would strongly recommend to explain how this code is working.
If you think that current folder / file structure is good, then I would recommend adding readme file that is specific to health monitoring library.

There I would expect some explanation on the approach taken and some description about folder structure.
This will help with maintainability and onboarding of new developers.

Added more doc. Note that the public API will get full doc only once the library stabilizes with other monitors to not need to rewrite docs that may change. If you need some specific additions, let me know.

src/health_monitoring_lib/cpp/include/score/hm/deadline/deadline_monitor.h

src/health_monitoring_lib/cpp/include/score/hm/common.h

NicolasFussberger · 2026-01-26T06:32:56Z

src/health_monitoring_lib/cpp/include/score/hm/health_monitor.h

+
+    ~HealthMonitor();
+
+    score::cpp::expected<deadline::DeadlineMonitor, Error> get_deadline_monitor(const IdentTag& tag);


In baselibs there is also score::Result datatype which achieves the same as score::cpp::expected but also provides an error message to the user in addition to the error code.
Probably, we should decide once which of these types we will use in the public API and then consistently use one of them.

I know, we can decide. I keep it kind of rust comaptible, where error is not restricted to be int32. I still prefer std::expected in this case.

src/health_monitoring_lib/cpp/include/score/hm/common.h

NicolasFussberger · 2026-01-26T06:49:26Z

src/health_monitoring_lib/cpp/include/score/hm/deadline/deadline_monitor.h

+    /// Adds a deadline with the given tag and duration range to the monitor.
+    DeadlineMonitorBuilder add_deadline(const IdentTag& tag, const TimeRange& range) &&;
+
+    ::score::cpp::optional<internal::FFIHandle> __drop_by_rust_impl()


I wonder if there is a way to make this method private/protected?
If I understand correctly, if the user would call this it would lead to undefined behavior.

It would not, it has defined behaviour.But I made it hidden

src/health_monitoring_lib/cpp/include/score/hm/common.h

paulquiring · 2026-01-26T08:53:09Z

The FFI part looks like the place where things can go elegantly and subtle wrong without being warned.

"In Rust unsafe is a keyword that allows programmers to bypass the compiler's automatic memory safety checks.."

I would very much like to see Sanitizer being used in cpp and rust. A good start would be the AddressSanitizer.

pawelrutkaq · 2026-01-26T09:13:40Z

The FFI part looks like the place where things can go elegantly and subtle wrong without being warned.

"In Rust unsafe is a keyword that allows programmers to bypass the compiler's automatic memory safety checks.."

I would very much like to see Sanitizer being used in cpp and rust. A good start would be the AddressSanitizer.

Correct! Feel free to create a ticket for that and bring this into the infrastructure team on how the asan shall be used in s-core (probably just a PR with a job integrated with bazel would be enough).

for the Rust, miri is tracked in s-core however it's bigger story for bazel. eclipse-score/score#2010

paulquiring · 2026-01-26T09:38:16Z

The FFI part looks like the place where things can go elegantly and subtle wrong without being warned.
"In Rust unsafe is a keyword that allows programmers to bypass the compiler's automatic memory safety checks.."
I would very much like to see Sanitizer being used in cpp and rust. A good start would be the AddressSanitizer.

Correct! Feel free to create a ticket for that and bring this into the infrastructure team on how the asan shall be used in s-core (probably just a PR with a job integrated with bazel would be enough).

for the Rust, miri is tracked in s-core however it's bigger story for bazel. eclipse-score/score#2010

bazel_cpp_toolchains offers features = ["asan"], for cc_test. This could be used for health_monitor_test.cpp.

pawelrutkaq · 2026-01-26T09:44:03Z

The FFI part looks like the place where things can go elegantly and subtle wrong without being warned.
"In Rust unsafe is a keyword that allows programmers to bypass the compiler's automatic memory safety checks.."
I would very much like to see Sanitizer being used in cpp and rust. A good start would be the AddressSanitizer.

Correct! Feel free to create a ticket for that and bring this into the infrastructure team on how the asan shall be used in s-core (probably just a PR with a job integrated with bazel would be enough).
for the Rust, miri is tracked in s-core however it's bigger story for bazel. eclipse-score/score#2010

bazel_cpp_toolchains offers features = ["asan"], for cc_test. This could be used for health_monitor_test.cpp.

Great, then we need to wait a bit for the toolchain being officially rolled out and then we can do it, for me, no issue. Can you please create ticket for it in this repo ? Btw cc_gtest_unit_test shall make use of it, maybe already supported, dont know.

paulquiring · 2026-01-26T09:52:51Z

The FFI part looks like the place where things can go elegantly and subtle wrong without being warned.
"In Rust unsafe is a keyword that allows programmers to bypass the compiler's automatic memory safety checks.."
I would very much like to see Sanitizer being used in cpp and rust. A good start would be the AddressSanitizer.

Correct! Feel free to create a ticket for that and bring this into the infrastructure team on how the asan shall be used in s-core (probably just a PR with a job integrated with bazel would be enough).
for the Rust, miri is tracked in s-core however it's bigger story for bazel. eclipse-score/score#2010

bazel_cpp_toolchains offers features = ["asan"], for cc_test. This could be used for health_monitor_test.cpp.

Great, then we need to wait a bit for the toolchain being officially rolled out and then we can do it, for me, no issue. Can you please create ticket for it in this repo ?

Here is an example how to use unreleased versions Using Unreleased Versions. It's a easy clean up once it's officially rolled out.

pawelrutkaq · 2026-01-26T10:18:35Z

The FFI part looks like the place where things can go elegantly and subtle wrong without being warned.
"In Rust unsafe is a keyword that allows programmers to bypass the compiler's automatic memory safety checks.."
I would very much like to see Sanitizer being used in cpp and rust. A good start would be the AddressSanitizer.

Correct! Feel free to create a ticket for that and bring this into the infrastructure team on how the asan shall be used in s-core (probably just a PR with a job integrated with bazel would be enough).
for the Rust, miri is tracked in s-core however it's bigger story for bazel. eclipse-score/score#2010

bazel_cpp_toolchains offers features = ["asan"], for cc_test. This could be used for health_monitor_test.cpp.

Great, then we need to wait a bit for the toolchain being officially rolled out and then we can do it, for me, no issue. Can you please create ticket for it in this repo ?

Here is an example how to use unreleased versions Using Unreleased Versions. It's a easy clean up once it's officially rolled out.

#50

SimonKozik · 2026-01-26T10:48:38Z

src/health_monitoring_lib/cpp/deadline_monitor.cpp

+#include "score/hm/deadline/deadline_monitor.h"
+#include "ffi_helpers.h"
+
+extern "C" {


Please note that there is not much comments in the code, there is also no description in readme file on the approach taken in this PR.

I would strongly recommend to explain how this code is working.
If you think that current folder / file structure is good, then I would recommend adding readme file that is specific to health monitoring library.

There I would expect some explanation on the approach taken and some description about folder structure.
This will help with maintainability and onboarding of new developers.

src/health_monitoring_lib/BUILD

FScholPer · 2026-01-27T11:35:51Z

.clang-format

If would say lets move that to the module template

anyway needed here or ? but should be in module template, agree

FScholPer · 2026-01-27T11:38:18Z

src/health_monitoring_lib/BUILD

 rust_library(
    name = "health_monitoring_lib",
-    srcs = glob(["src/**/*.rs"]),
+    srcs = glob(["rust/**/*.rs"]),


is that right?!

yes, i made it symetric to cpp

FScholPer · 2026-01-27T11:40:05Z

src/health_monitoring_lib/cpp/health_monitor.cpp

@@ -0,0 +1,108 @@
+/********************************************************************************


I think we need some small test for the ffi call

I would do more UT on cpp side, either after all points of API and other are fine for everyone or as follow up, since I would prefer to have at least a second monitor (checkpoints) before making impl bit locked by UT

arkjedrz · 2026-01-27T13:43:18Z

docs/module/health_monitor/detailed_design/index.rst

+Implementation structure
+------------------------
+
+src


.. code-block:: bash src └── health_monitoring_lib ├── cpp # C++ API using Rust FFI │ ├── include # C++ public header files. │ │ └── ... │ └── tests └── rust # Rust implementation + FFI for C++ └── deadline

arkjedrz · 2026-01-27T13:55:59Z

src/health_monitoring_lib/cpp/include/score/hm/deadline/deadline_monitor.h

+
+#include <score/expected.hpp>
+#include <score/hm/common.h>
+#include <functional>


-> #include <optional>?

arkjedrz · 2026-01-27T14:04:09Z

src/health_monitoring_lib/rust/deadline/deadline_monitor.rs

        DeadlineMonitor::new(self.deadlines)
    }
+
+    pub(crate) fn _add_deadline_internal(&mut self, tag: &IdentTag, range: TimeRange) {


-> add_deadline_internal? It's already crate-internal and used, why prefix with _?

pawelrutkaq added 2 commits January 22, 2026 15:01

Enable clangd indexing for codebase

9b83e6b

Create rust FFI layer

3f8531d

pawelrutkaq temporarily deployed to workflow-approval January 22, 2026 14:02 — with GitHub Actions Inactive

pawelrutkaq requested a review from Copilot January 22, 2026 14:02

Copilot AI reviewed Jan 22, 2026

View reviewed changes

Add CPP DeadlineMonitoring API

c14bf3c

pawelrutkaq force-pushed the pawelrutkaq_deadline_monitor_cpp branch from c1dd35a to 28fbfd4 Compare January 22, 2026 14:24

pawelrutkaq temporarily deployed to workflow-approval January 22, 2026 14:24 — with GitHub Actions Inactive

Fix formatting, copyrights

b9c92b8

pawelrutkaq force-pushed the pawelrutkaq_deadline_monitor_cpp branch from 28fbfd4 to b9c92b8 Compare January 22, 2026 14:25

pawelrutkaq temporarily deployed to workflow-approval January 22, 2026 14:25 — with GitHub Actions Inactive

Fix QNX8 build

85ecdb7

pawelrutkaq temporarily deployed to workflow-approval January 23, 2026 07:54 — with GitHub Actions Inactive

arkjedrz suggested changes Jan 23, 2026

View reviewed changes

SimonKozik reviewed Jan 23, 2026

View reviewed changes

MaciejKaszynski reviewed Jan 23, 2026

View reviewed changes

src/health_monitoring_lib/BUILD Show resolved Hide resolved

scripts/generate_cpp_compile_commands.sh Show resolved Hide resolved

SimonKozik reviewed Jan 23, 2026

View reviewed changes

NicolasFussberger reviewed Jan 26, 2026

View reviewed changes

src/health_monitoring_lib/cpp/include/score/hm/deadline/deadline_monitor.h Outdated Show resolved Hide resolved

NicolasFussberger reviewed Jan 26, 2026

View reviewed changes

src/health_monitoring_lib/cpp/include/score/hm/common.h Outdated Show resolved Hide resolved

NicolasFussberger reviewed Jan 26, 2026

View reviewed changes

src/health_monitoring_lib/cpp/include/score/hm/common.h Outdated Show resolved Hide resolved

NicolasFussberger reviewed Jan 26, 2026

View reviewed changes

src/health_monitoring_lib/cpp/include/score/hm/common.h Outdated Show resolved Hide resolved

pawelrutkaq temporarily deployed to workflow-approval January 26, 2026 10:15 — with GitHub Actions Inactive

pawelrutkaq mentioned this pull request Jan 26, 2026

Use Sanitizers #50

Open

pawelrutkaq requested review from MaciejKaszynski, NicolasFussberger, SimonKozik and arkjedrz January 26, 2026 10:18

Fixes after review

f31d045

pawelrutkaq force-pushed the pawelrutkaq_deadline_monitor_cpp branch from 77d3142 to f31d045 Compare January 26, 2026 10:20

pawelrutkaq temporarily deployed to workflow-approval January 26, 2026 10:20 — with GitHub Actions Inactive

SimonKozik suggested changes Jan 26, 2026

View reviewed changes

MaciejKaszynski suggested changes Jan 26, 2026

View reviewed changes

src/health_monitoring_lib/BUILD Show resolved Hide resolved

MaciejKaszynski approved these changes Jan 26, 2026

View reviewed changes

Add more docs

ea43d94

pawelrutkaq temporarily deployed to workflow-approval January 26, 2026 13:07 — with GitHub Actions Inactive

Symetric folders layout

3ffec5b

pawelrutkaq temporarily deployed to workflow-approval January 26, 2026 13:12 — with GitHub Actions Inactive

FScholPer reviewed Jan 27, 2026

View reviewed changes

arkjedrz reviewed Jan 27, 2026

View reviewed changes


		~HealthMonitor();

		score::cpp::expected<deadline::DeadlineMonitor, Error> get_deadline_monitor(const IdentTag& tag);

		@@ -0,0 +1,108 @@
		/********************************************************************************

Deadline monitoring CPP API #48

Are you sure you want to change the base?

Deadline monitoring CPP API #48

Uh oh!

Conversation

pawelrutkaq commented Jan 22, 2026

Uh oh!

github-actions bot commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

License Check Results

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Jan 22, 2026

Uh oh!

pawelrutkaq commented Jan 22, 2026

Uh oh!

arkjedrz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pawelrutkaq Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

NicolasFussberger Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pawelrutkaq Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Jan 22, 2026 •

edited

Loading

pawelrutkaq Jan 26, 2026 •

edited

Loading

NicolasFussberger Jan 26, 2026 •

edited

Loading

pawelrutkaq Jan 26, 2026 •

edited

Loading

pawelrutkaq commented Jan 26, 2026 •

edited

Loading

pawelrutkaq commented Jan 26, 2026 •

edited

Loading