sync signal with future

[fujitatomoya]

Description

This replaces platform specific signal synchronization into std::future.
This should be better for maintenance and code quality depending on standard library.

Is this user-facing behavior change?

No

Did you use Generative AI?

Yes, GitHub Copilot(Claude Sonnet 4)

Additional Information

[Copilot]

Pull Request Overview

This PR attempts to replace platform-specific semaphore implementations (Windows, macOS, POSIX) with standard C++ std::future/std::promise for signal synchronization. While this simplification is well-intentioned for maintainability, the implementation has a critical flaw: promises and futures are single-use synchronization primitives that cannot handle multiple signals, whereas semaphores support multiple post/wait cycles.

Key Changes:

• Replaced platform-specific semaphore code with std::promise<void> and std::future<void>
• Removed Windows (CreateSemaphore/WaitForSingleObject), macOS (dispatch_semaphore_t), and POSIX (sem_t) specific implementations
• Added <future> and <memory> includes

Critical Issue: After the first signal sets the promise value, the future remains ready permanently. Subsequent wait_for_signal() calls return immediately instead of blocking, creating a busy-wait loop. The previous semaphore implementation correctly handled multiple signal events.

Reviewed Changes

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

File	Description
rclcpp/src/rclcpp/signal_handler.hpp	Updated member variables from platform-specific semaphore types to std::unique_ptr<std::promise<void>> and std::unique_ptr<std::future<void>>; added <future> and <memory> includes
rclcpp/src/rclcpp/signal_handler.cpp	Replaced semaphore-based setup_wait_for_signal(), teardown_wait_for_signal(), wait_for_signal(), and notify_signal_handler() implementations with promise/future-based equivalents that have single-use semantics

---

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

[fujitatomoya]

@jmachowinski can you take a look?

[fujitatomoya]

Pulls: #2998
Gist: https://gist.githubusercontent.com/fujitatomoya/44b3786b6c45b77a0e8e267b74e536ac/raw/b7bbfc4f773fb6be421f270b3293d3466645bf35/ros2.repos
BUILD args: --packages-above-and-dependencies ‎rclcpp
TEST args: --packages-above ‎rclcpp
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/17567

• Linux
• Linux-aarch64
• Linux-rhel
• Windows

[fujitatomoya]

CI fails with Package '‎rclcpp' specified with --packages-above-and-dependencies was not found... weird...

[fujitatomoya]

• Linux
• Linux-aarch64
• Linux-rhel
• Windows

[jmachowinski]

I played around with the code and see multiple problems:

• Future is the wrong primitive, std::conditional_variable is more what we are looking for
• signal_handlers can interrupt each other, having a mutex taken in one is therefore a bad idea

I created #2999 as a poc, note it's not tested etc

[ahcorde]

Pulls: #2998
Gist: https://gist.githubusercontent.com/ahcorde/682b5a22ed6ab20a9f2c8d2cbebc9b44/raw/b7bbfc4f773fb6be421f270b3293d3466645bf35/ros2.repos
BUILD args: --packages-above-and-dependencies rclcpp
TEST args: --packages-above rclcpp
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/17599

• Linux
• Linux-aarch64
• Linux-rhel
• Windows

[fujitatomoya]

@jmachowinski thanks for #2999, i am fine to replace this with it.