Skip to content

Conversation

@fujitatomoya
Copy link
Collaborator

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

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Collaborator Author

@jmachowinski can you take a look?

@fujitatomoya
Copy link
Collaborator Author

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 Build Status
  • Linux-aarch64 Build Status
  • Linux-rhel Build Status
  • Windows Build Status

@fujitatomoya fujitatomoya changed the title Fujitatomoya/sync signal with future sync signal with future Nov 21, 2025
@fujitatomoya
Copy link
Collaborator Author

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

@fujitatomoya
Copy link
Collaborator Author

  • Linux Build Status
  • Linux-aarch64 Build Status
  • Linux-rhel Build Status
  • Windows Build Status

@jmachowinski
Copy link
Collaborator

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
Copy link
Contributor

ahcorde commented Nov 24, 2025

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 Build Status
  • Linux-aarch64 Build Status
  • Linux-rhel Build Status
  • Windows Build Status

@fujitatomoya
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants