Introduce new `Component` class by danth · Pull Request #705 · eclipse-score/lifecycle

danth · 2026-09-28T12:05:13Z

Start, stop, force stop, and ready conditions are now implemented as strategies which plug in to a central Component class.

The only interaction between these classes is a tiny Handle struct, which identifies the child process to act upon.

Ideally, the handle will stay internal to the Component, and higher level classes such as ProcessGroupManager and the Graph will have no knowledge of the underlying process.

This new architecture should improve:

ProcessInfoNode having a mixture of process- and component-level code.
ProcessLauncher also having code for process termination.
Difficulty in adding new ready conditions and component types.

As a start, this pull request just introduces the new classes, and has them call the existing ProcessLauncher from its original location.

Once the new component class is ready, we can change the Graph to start using it in place of ProcessInfoNode. Currently it is unused outside of tests.

Finally, we will clean up by moving the old code into its new locations (rather than just calling it).

NicolasFussberger · 2026-09-29T09:05:24Z

+
+    for (const IReadyCondition* ready_condition : ready_conditions_)
+    {
+        const osal::OsalReturnType result = ready_condition->wait(handle_.value());


Currently we have one overall ready timeout for the component.

if we had multiple ready conditions, I think this would mean all ready condition must be fulfilled within the ready_timeout. So it would not be that each ready condition can take the full ready timeout.

This makes me think that it could make sense to move the timeout checking in the component. Same for the shutdown timeout

NicolasFussberger · 2026-09-29T09:06:27Z

+    {
+        return score::cpp::make_unexpected(ComponentError::kErrorBeforeReady);
+    }
+    handle_ = result.value();


I wonder how to handle the case that the component crashes before ready condition is fulfilled.
Is this in the responsibility of each ready condition to continuously check if the component is still running?

NicolasFussberger · 2026-09-29T09:13:43Z

+}
+
+Component::Component(
+    const IStartAction* start_action,


With the division into start/stop actions I am wondering what is keeping track of the process state.
What will own the process handle?

I think at every point in time we need to know what is the state of any process we started, and what is the state of the component

The handle is owned by the component, and should track the state of the underlying resource (a process, a container, etc) but not the state of the component itself. It may be useful to make the handle mutable, for example to clear the PID if the process has crashed.

Currently the state at the component level is just whether or not a handle currently exists. But this should be extended to an enum such as starting, stopping, failed... which is updated as we run each action and in response to external events.

NicolasFussberger · 2026-09-29T10:20:23Z

+    return score::cpp::make_unexpected(ComponentError::kErrorAfterReady);
+}
+
+IComponent::RequestResult Component::tryHandleTermination(int32_t status)


I wonder how to judge now if the process crashed or was intentionally terminated (as the result of the stop_action/force_stop_action or the process is configured as self-terminating and we are waiting for this in the ready condition).

Similar to the other comment, we could store this state at the component level.

NicolasFussberger · 2026-09-29T10:27:03Z

+
+    if (process.pid > 0)
+    {
+        if (kill(process.pid, SIGTERM) == 0)


I think we'll need to decide where the timeout monitoring takes place for the shutdown and the escalation to SIGKILL in case of timeout

NicolasFussberger · 2026-09-29T10:28:45Z

+                return score::cpp::make_unexpected(ComponentError::kActivationTimedOut);
+        }
+    }
+


I think we'll need to decide how the supervision is handled.
I think a natural point would be to start supervision here after all ready conditions are fulfilled.

Currently, this will always translate to start supervision when kRunning reported.

Though for this we also need the timestamp from the kRunning report, as the supervision has to be started exactly at this timestamp.

Maybe it would be possible to have IpcCommsSync store the timestamp (as it should happen only once per instance). That is already stored inside ProcessHandle, so it would be accessible to the supervision.

This uses the existing component interface, so it should be fully compatible with existing callers.

This will be needed to remove the direct use of process identifiers in `Graph::forceKillProcesses`, making it flexible to other kinds of components.

These will be used for run targets, which do not contain any underlying process.

These use the existing `ProcessLauncher` for the time being; eventually the code from `ProcessLauncher` should be migrated into the actions themselves.

Follow the naming conventions.

github-project-automation Bot added this to LCM - Lifecycle & Health FT Sep 28, 2026

github-project-automation Bot moved this to Backlog in LCM - Lifecycle & Health FT Sep 28, 2026

danth requested a deployment to workflow-approval September 28, 2026 12:05 — with GitHub Actions Waiting

danth force-pushed the pin-split branch from e5118a7 to aca0980 Compare September 28, 2026 12:21

danth requested a deployment to workflow-approval September 28, 2026 12:21 — with GitHub Actions Waiting

danth force-pushed the pin-split branch from aca0980 to adeb5a9 Compare September 28, 2026 13:41

danth requested a deployment to workflow-approval September 28, 2026 13:41 — with GitHub Actions Waiting

NicolasFussberger reviewed Sep 29, 2026

View reviewed changes

Comment thread score/launch_manager/src/daemon/src/process_group_manager/details/process_launcher.hpp

danth force-pushed the pin-split branch from adeb5a9 to 65e7d2a Compare September 30, 2026 12:03

danth requested a deployment to workflow-approval September 30, 2026 12:03 — with GitHub Actions Waiting

danth requested a deployment to workflow-approval September 30, 2026 13:35 — with GitHub Actions Waiting

danth changed the title ~~Refactor ProcessInfoNode and ProcessLauncher~~ Introduce new Component class Sep 30, 2026

danth requested a deployment to workflow-approval September 30, 2026 14:34 — with GitHub Actions Waiting

danth requested a deployment to workflow-approval October 2, 2026 09:49 — with GitHub Actions Waiting

danth requested a deployment to workflow-approval October 2, 2026 09:51 — with GitHub Actions Waiting

danth requested a deployment to workflow-approval October 2, 2026 10:05 — with GitHub Actions Waiting

danth added 15 commits October 2, 2026 16:31

Implement new component class

b073b46

This uses the existing component interface, so it should be fully compatible with existing callers.

Move start action, stop action, ready condition to subfolders

272ad89

Add force stop actions

35ccc51

This will be needed to remove the direct use of process identifiers in `Graph::forceKillProcesses`, making it flexible to other kinds of components.

Add empty actions

c65b2fb

These will be used for run targets, which do not contain any underlying process.

Allow actions to return an error code

3a021ba

Add process actions

83b7780

These use the existing `ProcessLauncher` for the time being; eventually the code from `ProcessLauncher` should be migrated into the actions themselves.

Add unit tests for new actions

68f64f9

Add report running ready condition

d166710

Pass through stop_token from the component to the actions

34a9e93

Use references rather than pointers in Component

9d7e84b

Use cpp::span rather than std::vector for ready conditions

d0b50d1

Add docstrings for new classes

ab51ecc

Add file ready condition

ee959e0

Rename force_stop to forceStop

f7df5af

Follow the naming conventions.

Replace kNotImplemented returns with panics

04bc7e9

danth force-pushed the pin-split branch from 9affb21 to 04bc7e9 Compare October 2, 2026 15:32

danth requested a deployment to workflow-approval October 2, 2026 15:32 — with GitHub Actions Waiting

Navigation Menu

Introduce new `Component` class - #705

Introduce new `Component` class#705
danth wants to merge 15 commits into
eclipse-score:mainfrom
etas-contrib:pin-split

danth commented Sep 28, 2026 •

edited

Loading

Uh oh!

NicolasFussberger Sep 29, 2026

Uh oh!

NicolasFussberger Sep 29, 2026

Uh oh!

Uh oh!

Uh oh!

NicolasFussberger Sep 29, 2026

Uh oh!

danth Sep 29, 2026

Uh oh!

NicolasFussberger Sep 29, 2026

Uh oh!

danth Sep 29, 2026

Uh oh!

NicolasFussberger Sep 29, 2026

Uh oh!

NicolasFussberger Sep 29, 2026

Uh oh!

danth Sep 29, 2026

Uh oh!

Uh oh!

This branch is waiting to be deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

danth commented Sep 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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!

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!

This branch is waiting to be deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

danth commented Sep 28, 2026 •

edited

Loading