-
Notifications
You must be signed in to change notification settings - Fork 145
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
Conversation
Similar to asyncio._UnixSelectorEventLoop.add_signal_handler() implementation, but not limited to Unix platforms. Signed-off-by: Michel Hidalgo <[email protected]>
This is lacking tests and quite a bit of documentation. But I wanted to share this POC as soon as possible for thorough scrutiny. |
There was a problem hiding this 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?
And yes, it needs docs and tests if we can manage to make them (can be hard with these kind of things). |
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
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 |
If this patch gets merged, I'd like to see if it fixes ros2/build_farmer#248. |
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
There was a problem hiding this 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]>
Of course, it wasn't enough... See 71ab3f2. |
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Going in! As a side note, we should sort out |
Signed-off-by: Michel Hidalgo <[email protected]>
* 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]>
@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 Issue with further details: #666 |
Connected to #473. This patch uses
signal.set_wakeup_fd
to delegate signal handling to the running loop. Similar toasyncio._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.