Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle signals within the asyncio loop. #476

Merged
merged 9 commits into from
Jan 12, 2021
Merged

Conversation

hidmic
Copy link
Contributor

@hidmic hidmic commented Dec 16, 2020

Connected to #473. This patch uses signal.set_wakeup_fd to delegate signal handling to the running loop. Similar to asyncio._UnixSelectorEventLoop.add_signal_handler() implementation, but not limited to Unix platforms.

For additional context, without this patch, in a scenario like the one in #473, events emitted within a signal handler do not seem to wake up the loop.

Similar to asyncio._UnixSelectorEventLoop.add_signal_handler()
implementation, but not limited to Unix platforms.

Signed-off-by: Michel Hidalgo <[email protected]>
@hidmic hidmic changed the title Handle signals within the asyncio loop. [POC] Handle signals within the asyncio loop. Dec 16, 2020
@hidmic
Copy link
Contributor Author

hidmic commented Dec 16, 2020

This is lacking tests and quite a bit of documentation. But I wanted to share this POC as soon as possible for thorough scrutiny.

Copy link
Member

@wjwwood wjwwood left a comment

Choose a reason for hiding this comment

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

The changes make sense to me, but I haven't dug deeply into the signal handler provided by the loop and I haven't tried it out locally.

This is good for me, if we can show it works well on all the platforms.

Have you tried it when the launch service is not in the main thread?

@wjwwood
Copy link
Member

wjwwood commented Dec 17, 2020

And yes, it needs docs and tests if we can manage to make them (can be hard with these kind of things).

@hidmic hidmic changed the title [POC] Handle signals within the asyncio loop. Handle signals within the asyncio loop. Dec 23, 2020
@hidmic
Copy link
Contributor Author

hidmic commented Dec 23, 2020

Have you tried it when the launch service is not in the main thread?

It won't work, as signal handling API is restricted to the main thread. But that's a limitation we already had. See here and here). Also #126.


FWIW I think we should eventually drop signal handling within launch.LaunchService. Some async-signal-safe APIs for a user to setup their own handlers would pose less restrictions on usage. Moreover, if we could replace signals with a less rudimentary IPC to monitor and interrupt subprocesses, that'd lift all concurrency limitations and improve launch behavior on Windows.

@hidmic
Copy link
Contributor Author

hidmic commented Dec 23, 2020

CI up to launch, test_launch_ros, and test_communication:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

@hidmic
Copy link
Contributor Author

hidmic commented Dec 23, 2020

If this patch gets merged, I'd like to see if it fixes ros2/build_farmer#248.

launch/launch/utilities/signal_management.py Outdated Show resolved Hide resolved
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Copy link
Member

@ivanpauno ivanpauno left a comment

Choose a reason for hiding this comment

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

Code too handle the windows quirks seems reasonable too me!

Signed-off-by: Michel Hidalgo <[email protected]>
@hidmic
Copy link
Contributor Author

hidmic commented Dec 23, 2020

Code too handle the windows quirks seems reasonable too me!

Of course, it wasn't enough... See 71ab3f2.

@hidmic
Copy link
Contributor Author

hidmic commented Dec 23, 2020

CI up to launch, test_launch_ros, and test_communication:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

Signed-off-by: Michel Hidalgo <[email protected]>
@hidmic
Copy link
Contributor Author

hidmic commented Jan 12, 2021

CI up to launch, test_launch_ros, test_communication, and osrf_pycommon:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

@hidmic
Copy link
Contributor Author

hidmic commented Jan 12, 2021

Going in! As a side note, we should sort out asyncio usage in launch at some point. It goes great lengths to ensure loop locality, and asyncio API is set up for global loops.

@hidmic hidmic merged commit 3d77b5d into master Jan 12, 2021
@delete-merged-branch delete-merged-branch bot deleted the hidmic/fix-signal-handling branch January 12, 2021 21:54
mjeronimo pushed a commit that referenced this pull request May 4, 2021
hidmic pushed a commit that referenced this pull request Jul 7, 2021
* Handle signals within the asyncio loop. (#476)
* Workaround asyncio signal handling on Unix (#479)
* Remove is_winsock_handle() and instead test if wrapping the handle in a socket.socket() works (#494)
* Close the socket pair used for signal management (#497)
* Only try to wrap the fd in a socket on Windows (#498)
* Bring back deprecated launch.utilities.signal_management APIs

Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
@ciandonovan
Copy link

@hidmic This merge broke SIGTERM handling in Launch by removing the signal handler and not replacing it.

SIGINT wasn't broken only because Python installs a signal handler for it by default, translating it into a KeyboardInterrupt exception.

Issue with further details: #666
Pull request fixing it: #712

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