-
Notifications
You must be signed in to change notification settings - Fork 159
Complete #506 backport and deprecate signal_management APIs #511
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
Merged
hidmic
merged 10 commits into
mjeronimo/backport-476-to-foxy
from
hidmic/adapt/mjeronimo/backport-476-to-foxy
Jun 29, 2021
Merged
Changes from all commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
9bc5fea
Workaround asyncio signal handling on Unix (#479)
hidmic 20c21a6
Remove is_winsock_handle() and instead test if wrapping the handle in…
ivanpauno 31b3277
Close the socket pair used for signal management (#497)
ivanpauno 90c1cba
Only try to wrap the fd in a socket on Windows (#498)
ivanpauno 8ca87d8
Bring back deprecated launch.utilities.signal_management APIs
hidmic 56942c2
Have launch.utilities.signal_management tests passing
hidmic 4b7e29b
No SIGQUIT on Windows
hidmic 9b88259
Skip SIGQUIT test on Windows
hidmic d8e320a
Drop deprecation warnings
hidmic 7a89f67
Revert "Drop deprecation warnings"
hidmic File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I'd rather not release deprecation warnings into a long-standing ROS distro to avoid disruption. Besides, users who have already switched to Galactic would have already run into the API change without a tick-tock cycle. There may be other opinions.
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.
I can only give one user's opinion (mine/my team's): I'd like to get warned of breakages as soon a possible. We'd have to change it eventually in any way since we move over to newer versions of ROS2 eventually (LTS -> LTS). And if not, a
warnings.simplefilter()ist easy to implement if one does not want to see the message for the time being.But you know best what's common practice in ROS. This isn't Rolling Ridley, after all.
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.
I have to agree with @jacobperron ; I don't think we should introduce new deprecation warnings into a stable distribution. Having new warnings show up for Foxy users as a result of
sudo apt-get updateis really user-unfriendly.When people port to Galactic or Rolling, they'll get the warnings.
Uh oh!
There was an error while loading. Please reload this page.
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.
Alright, see d8e320a.
However I will say that, while I agree that introducing warnings into a patch release of a stable distribution is not ideal, this patch is not transparent. Signals now go through wakeup file descriptors and handling is deferred to the main-thread local
asyncioloop (assuming it is run). Depending on how the old signal management API was used (the only case in which you'd get a warning) this can potentially break those use cases -- silently as of d8e320a.Which is why I didn't even think of backporting anything, and I probably wouldn't if these bits were not kinda broken in Foxy.
The old API was completely removed in Galactic, so no warnings (there's no way to re-implement it in terms of the new API so as to be functionally equivalent, as exposed above). This patch is a retrofit of the original patch.
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.
I didn't fully comprehend the nature of the change. If there's a risk that we're breaking somebody, then I think issuing a warning is a good thing. I don't like the idea of releasing breaking changes in Foxy, but if you think the fix is worth the potential churn then I'd rather be very loud about it.
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.
So, without this fix,
launchhangs every now and then. It's the same we've experienced withros2clitests before. And it hit @felixdivo, so it may hit others too.I agree about being loud. I thought a warning would be OK, but perhaps it's too loud. @clalancette ?
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.
It seems like we are stuck between a rock and a hard place. While I don't like introducing new warnings into a stable distribution, silently breaking users isn't good either.
In this case, I'll defer to your best judgement on what to do here. You obviously have a much better handle on the issue and launch in general than I do.
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.
Presumably, the these signal APIs are not very popular so I'd hope the number of affected users would be small.
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.
Alright, I put deprecation warnings back in. I'll merge this PR into #506 and run CI there.