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

Ensure waitables handle guard condition retriggering #2420

Conversation

wjwwood
Copy link
Member

@wjwwood wjwwood commented Jan 30, 2024

An emerging responsibility of Waitables that wasn't explicitly declared before is that they should be ensuring guard conditions should stay ready between waits so long as the condition for them being triggered is still true.

Some waitables will not need this, e.g. waitables that are used to only wake up an executor once, but don't have events tied to them don't need to be retriggered. But other waitables which use guard conditions to notify the executor of work to be done need to keep triggering those guard conditions on subsequent waits, so long as the work associated with them has not been completed.

This is still a WIP. I'll add more cross references and details here in the future.

@jmachowinski
Copy link
Contributor

lgtm, execpt for the dummy stuff ;-)

@mjcarroll
Copy link
Member

@wjwwood I went through and cleaned out the dummy functions here

@jmachowinski
Copy link
Contributor

@wjwwood Looking at you const changes to the execute API, it occurred to me, that it might be way better to use a std::unique_ptr here.

I got two motivations for this proposal:

  • Performance.
    Shared_ptr are relative expensive to copy around, as they trigger a cache lock. And we are in a hot code path, that is executed with a real high frequency.
  • Cleaner semantics.
    The waitable should drop the ownership of the taken data, and should have no way of changing it, after the take_data.

@mjcarroll
Copy link
Member

I especially agree on the clearer semantics in this case.

@wjwwood
Copy link
Member Author

wjwwood commented Feb 27, 2024

I will look into the feasibility of using unique_ptr, but I will point out that the performance shouldn't be an issue since we're not copying the shared ptr in the interface I'm touching, but by taking a const-ref to shared_ptr we allow for the function to copy it if needed.

Also for semantics, const-ref to shared_ptr implies copy is possible but not guaranteed (see: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-sharedptrparam-const), so the semantics are clear enough to me at least, but maybe unique_ptr is actually sufficient (which would imply taking ownership as you all said: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-uniqueptrparam)

@wjwwood
Copy link
Member Author

wjwwood commented Feb 27, 2024

What was there before, non-const-ref to shared_ptr, is definitely not what we want to convey in the APIs semantics, i.e. that it might reset/reseat the given pointer (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-sharedptrparam).

@jmachowinski
Copy link
Contributor

I will point out that the performance shouldn't be an issue since we're not copying the shared ptr in the interface I'm touching

The data pointer needs to be copied at least one time into the AnyExecutable.

@mjcarroll
Copy link
Member

@mjcarroll to run CI on this.

@mjcarroll mjcarroll marked this pull request as ready for review March 22, 2024 18:05
@mjcarroll
Copy link
Member

I think that this is actually ready for review. I'm going to run CI to at least see where we are at on it.

@mjcarroll
Copy link
Member

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

@wjwwood wjwwood force-pushed the wjwwood/ensure_waitables_handle_guard_condition_retriggering branch 2 times, most recently from bf03d2f to c15d924 Compare March 27, 2024 20:22
@wjwwood wjwwood changed the base branch from rolling to mjcarroll/rclcpp_waitset_executor March 27, 2024 20:22
@wjwwood
Copy link
Member Author

wjwwood commented Mar 27, 2024

I retargeted this onto #2142 temporarily until it is merged, then I'll retarget it to rolling.

wjwwood and others added 4 commits March 27, 2024 13:33
…gging code still there

Signed-off-by: William Woodall <william@osrfoundation.org>
Signed-off-by: Michael Carroll <mjcarroll@intrinsic.ai>
Signed-off-by: William Woodall <william@osrfoundation.org>
@wjwwood wjwwood force-pushed the wjwwood/ensure_waitables_handle_guard_condition_retriggering branch from c15d924 to 3fa7416 Compare March 27, 2024 20:42
@delete-merged-branch delete-merged-branch bot deleted the branch mjcarroll/rclcpp_waitset_executor March 29, 2024 03:22
@wjwwood
Copy link
Member Author

wjwwood commented Mar 29, 2024

I'd like to merge #2467 before pushing this one for review.

@wjwwood
Copy link
Member Author

wjwwood commented Mar 30, 2024

Now that #2467 is merged, I need to fix this pr up, which I will do asap.

@jmachowinski
Copy link
Contributor

@wjwwood I rebase this on head an cleaned it up a bit :
https://github.com/jmachowinski/rclcpp/tree/ensure_waitables_handle_guard_condition_retriggering

Note, I removed the SubscriptionIntraProcess::add_to_wait_set as its already handled in the base class.

@wjwwood
Copy link
Member Author

wjwwood commented Apr 3, 2024

Thanks, but I don't see any changes yet. Still has conflicts, did you push? Either way I was already working on the fix up, sorry for the duplication of effort.

Edit: I see you put it on a different branch, thanks. I'll compare what I had been working on.

@wjwwood wjwwood force-pushed the wjwwood/ensure_waitables_handle_guard_condition_retriggering branch from 3fa7416 to 569921e Compare April 3, 2024 22:43
@wjwwood
Copy link
Member Author

wjwwood commented Apr 4, 2024

Trying to close and reopen the pr to fix the processing of new commits...

@wjwwood
Copy link
Member Author

wjwwood commented Apr 4, 2024

It won't let me reopen it because the current target branch has been deleted, and I cannot edit it to change the target branch while closed, so I made a new pr: #2483

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.

3 participants