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

I think we could pass a timeout into the ready condition when it is called (rather than storing it). Then on each iteration through the list the component could calculate the remaining time until the overall deadline.

Actually I think it would be nice to pass a struct/class like Go contexts which has both a deadline and a stop token.

Then the ready condition can stop either when the deadline expires or cancellation is requested.

Timeouts will be implemented in a separate pull request. :))

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

Timeouts will be implemented in a later pull request.

Follow the naming conventions.

This is based on the diagram introduced in eclipse-score#736.

While `operator()` was slightly less code, the methods had to be public for it to work.

For invalid handles, we should move to the terminated state immediately, rather than waiting for a termination event.

This can be reintroduced once it is decided how a force stop is triggered. Link: https://github.com/eclipse-score/lifecycle/pull/705/changes#r4154237710

Just switch using if statements rather than a separate implementation for each state. This makes it more obvious how things work with concurrency.

Link: eclipse-score#705 (comment)

github-actions · 2026-10-16T15:50:14Z

Documentation preview for this pull request is available at:
pr-705: https://eclipse-score.github.io/lifecycle/pr-705/

NicolasFussberger · 2026-10-19T09:39:17Z

+    lock.unlock();
+    for (const IReadyCondition& ready_condition : ready_conditions_)
+    {
+        if (!ready_condition.wait(stop_activation.get_token(), handle).has_value())


The ready_condition gets a copy of the handle, so it will not actually observe if the pid was set to -1 if the process terminated inbetween. However, passing the actual reference to the handle from the state would lead to data race since there is no lock and oshandler thread also modifies it

I agree. However, no ready conditions rely on the PID at the moment.

Maybe we can leave this as an open point for now, to avoid blocking the pull request?

If so, I'll create a separate issue to address this :))

NicolasFussberger · 2026-10-19T09:51:32Z

+        return RequestState::kSuccess;
+    }
+
+    SCORE_LANGUAGE_FUTURECPP_UNREACHABLE_MESSAGE("If stop was not requested, then state must still be StartingState");


Is this actually reachable for self-terminating processes where no stop was requested in tryHandleTermination?

When no stop is requested, the state is not changed. So, if the activate method is still running, then the state must still be starting. If the process terminates after it enters the ready state, activate has already returned so the assertion is not reached

NicolasFussberger · 2026-10-19T10:12:50Z

+    if (self_terminating_ && status == 0)
+    {
+        return RequestState::kWaiting;
+    }


How do we move from Starting->Ready for a self-terminating process that has ready condition ProcessState:Terminated?
Is there a ReadyCondition currently missing for this case?

Yes, the ready condition is missing because we were waiting for #738. As a separate pull request we can adapt that code to implement the ready condition interface

Link: eclipse-score#705 (comment)

NicolasFussberger · 2026-10-22T11:14:01Z

This PR introduces new classes which are not yet used by the production code.
Not all functionality is implemented yet and it will continue in further PRs before it will be enabled in the production code.

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 added 20 commits October 16, 2026 16:31

Add docstrings for new classes

9150542

Add file ready condition

4601d01

Rename force_stop to forceStop

0bf8cd6

Follow the naming conventions.

Replace kNotImplemented returns with panics

df2e12c

Add component state machine

307bd2f

This is based on the diagram introduced in eclipse-score#736.

Make component identifier const

e8fe4eb

Implement tryHandleTermination on Component

74dbc00

Interrupt ready conditions when the process terminates

1f65477

Encapsulate visitor methods within actions

2ed0e8d

While `operator()` was slightly less code, the methods had to be public for it to work.

Improve handling of self-terminating components

649598b

Invalidate process handle when the process terminates

c10319d

Allow stop actions to return either kWaiting or kSuccess

cda7747

For invalid handles, we should move to the terminated state immediately, rather than waiting for a termination event.

Remove incorrect force-stop test

470ff82

This can be reintroduced once it is decided how a force stop is triggered. Link: https://github.com/eclipse-score/lifecycle/pull/705/changes#r4154237710

Simplify component methods

b001665

Just switch using if statements rather than a separate implementation for each state. This makes it more obvious how things work with concurrency.

Take Handle& rather than Handle

676a9a7

Simplify actions by using std::get_if rather than std::visit

83b1314

Move process-specific code to an invalidate helper

9eff4b0

Avoid creating duplicate success events

6cd4abd

Link: eclipse-score#705 (comment)

Unblock ReportRunningReadyCondition if the process crashes

5563aa4

Fix duplicate definition of invalidate

07eceda

NicolasFussberger reviewed Oct 19, 2026

View reviewed changes

danth added 5 commits October 20, 2026 10:33

Make IReadyCondition::tryHandleTermination virtual

df1d279

Link: eclipse-score#705 (comment)

Only accept one ready condition per component

fe7aa32

Link: eclipse-score#705 (comment)

Assert that sync is not null

c8564a9

Fix crash when activation is cancelled from both sources

f6b4540

Link: eclipse-score#705 (comment)

Enter fault state if a start/stop action fails

cd30deb

NicolasFussberger approved these changes Oct 22, 2026

View reviewed changes

MaciejKaszynski approved these changes Oct 22, 2026

View reviewed changes

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!

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!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented Oct 16, 2026

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NicolasFussberger commented Oct 22, 2026

Uh oh!

This branch was successfully deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

danth commented Sep 28, 2026 •

edited

Loading