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

[Foxy] Handle signals within the asyncio loop. (#476) #506

Merged
merged 11 commits into from
Jul 7, 2021

Conversation

mjeronimo
Copy link

Signed-off-by: Michel Hidalgo [email protected]

Backporting #476 to Foxy.
Fixes: ros2/launch_ros#223

@mjeronimo mjeronimo requested review from hidmic and jacobperron May 4, 2021 18:45
@hidmic
Copy link
Contributor

hidmic commented May 4, 2021

If we backport #476, we have to backport #479, #494, #497, and #498 too. Signal handling is tricky (so much so that CPython itself is quite rough there).

@mjeronimo
Copy link
Author

@hidmic Do you recommend proceeding with those for Foxy? Is it worth it for this issue?

@hidmic
Copy link
Contributor

hidmic commented May 4, 2021

@mjeronimo all those PRs patch #476 in one way or another. #479 deals with an issue in asyncio that became a problem when signal management implementation changed in #476. #494, #497, and #498 fix issues in #476 in various ways (mainly for Windows).

This is why I did not proactively backport these changes. But ros2/launch_ros#223 suggests it may be worth the risk. #495 may be running into similar issues.

@mjeronimo
Copy link
Author

@jacobperron What do you think about backporting this set of changes to Foxy? Would like to get your input before proceeding.

@jacobperron
Copy link
Member

I'm okay with backporting all of the changes pointed out, as long as @hidmic doesn't have any major reservations about them. On the surface of it, it looks like it's worth the effort to improve things in Foxy, but I don't know enough about the signal handling changes to say if we're going to break users code.

Of all of the changes, the only thing I would change for Foxy would be to keep this function (unused) to maintain API compatibility:

https://github.com/ros2/launch/pull/494/files#diff-5dcef8ac9a56749cd4f33305fea85b4c918383b74c8c1369cce3a22286d84ee9L30

@hidmic
Copy link
Contributor

hidmic commented May 4, 2021

as long as @hidmic doesn't have any major reservations about them

No particular reservations. It's sensitive code, that's all (4 PRs followed #476).

Of all of the changes, the only thing I would change for Foxy would be to keep this function (unused) to maintain API compatibility:

That function didn't exist before #476, so it doesn't exist in Foxy. On the other hand, this patch removes quite a few functions in changes signal_management.py completely. Off the top of my head, I don't think we can keep that API around. Maybe as a no-op?

@felixdivo
Copy link

I can probably offer to help with testing these changes. It can't be too hard to set it up properly.

@felixdivo
Copy link

felixdivo commented May 15, 2021

The fix would be important for me / my team. Can I assist you in some way?

Keeping the old API and having it do nothing seems like the only sensible way (the only one with moderate coding effort). One should perhaps also print a warning pointing to this PR or otherwise explaining that the functionality has moved and the function won't do anything any more. That way, there is actually merit in keeping it.

Copy link
Member

@jacobperron jacobperron left a comment

Choose a reason for hiding this comment

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

I overlooked the changes in the PR originally (and only looked at the follow-up fixes).

I'm very hesitant about backporting this to Foxy since it breaks API. I think we should investigate either:

  1. Making an API-compatible fix here (or in launch_ros).
  2. Keeping the old API, and keep it functional.

I don't like the idea of making the old API a noop (even if it produces a warning). This can cause a subtle break for the user versus a hard break (if the API does not exist). If we are going to produce a warning, we may as well remove the old API since it forces the user to update instead of potentially having this break subtly.

Comment on lines 35 to 38
'install_signal_handlers',
'on_sigint',
'on_sigquit',
'on_sigterm',
Copy link
Member

Choose a reason for hiding this comment

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

Removing these APIs will break anyone using them directly.

@hidmic
Copy link
Contributor

hidmic commented May 19, 2021

Keeping the old API, and keep it functional.

Hmm, perhaps we can use the fact that asyncio loops are thread-local globals and re-implement this API with a global AsyncSignalSafeManager instance. I haven't thought through all the implications though.

@felixdivo
Copy link

I just want to ping this issue and find out what the roadmap might be. Is there someone willing to tackle this? I of course unterstand, that this is a rather nasty change and personally also do not want to dig into it.

So if the decision is taken that there simply will not be a fix and foxy will be left with the bug ☹️, it would be great to spell it out in this issue. That way, any stakeholder knows what to do. I my case, I will probably have to hack something together in our product until the next ROS2 LTS is released.

@hidmic
Copy link
Contributor

hidmic commented Jun 16, 2021

I just put together a POC in #511. It needs testing, and Foxy ROS Boss approval.

hidmic and others added 10 commits June 29, 2021 12:35
Unix asyncio loops override existing signal wakeup file descriptors with no regards for existing ones -- set by user code or by another loop

Signed-off-by: Michel Hidalgo <[email protected]>
… a socket.socket() works (#494)

Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
This reverts commit d8e320a.

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

hidmic commented Jun 29, 2021

Full Foxy CI:

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

@felixdivo
Copy link

As with #511, this PR should probably be added to the Foxy Patch Release 5

@hidmic
Copy link
Contributor

hidmic commented Jun 29, 2021

Test failures seem unrelated. Are we good to go @jacobperron @mjeronimo ?

@mjeronimo
Copy link
Author

Looks good to me. Thanks for taking on this complicated issue.

@hidmic
Copy link
Contributor

hidmic commented Jun 30, 2021

@jacobperron I'd like your blessing before I merge this.

@felixdivo
Copy link

Where should I look for a possible release date of the Foxy Patch Release 5 that this will be part of?

@hidmic hidmic requested a review from jacobperron July 7, 2021 14:13
@hidmic
Copy link
Contributor

hidmic commented Jul 7, 2021

Alright, moving forward !

@hidmic hidmic merged commit 4c60ea0 into foxy Jul 7, 2021
@delete-merged-branch delete-merged-branch bot deleted the mjeronimo/backport-476-to-foxy branch July 7, 2021 20:35
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.

5 participants