-
Notifications
You must be signed in to change notification settings - Fork 3.4k
[Proxying][Docs] Improve the docs for proxying with callback #18359
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
Conversation
The tests in test_pthread_proxying_cpp proxy functions that increment local variables. For the async proxying functions, the proxying is followed by a wait on a condition variable so the test can assert that the proxied work was completed. However, the incrementing of the local variables was not protected by the lock used with the condition variable, so it was possible for the variable to be incremented and the condition variable notified after checking the wait condition but before waiting. Since the condition variable would not be notified again, the test would wait on the condition variable forever. Fix the bug by taking the lock before incrementing the variable in tests where this could cause problems. Fixes #18353.
Make it clear that work is asynchronously proxied in both directions and that the return code is determined only by whether the initial work is proxied.
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
What happens if it fails the second enqueue operation? Is it silently dropped or do we abort? |
It's silently dropped, but the only way that can happen is if there is an allocation failure, and those are typically assumed not to happen in practice. I suppose we could abort instead. Do you think that would be better? |
I think aborting is better, though I could see a case for removing that check in a no-assertions build. Might be worth documenting that either way. Was that already an issue with the previous proxying commands? |
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.
Either way lgtm, thanks, this PR is a good improvement.
{ | ||
std::unique_lock<std::mutex> lock(mutex); | ||
i = 3; | ||
} |
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.
From the other change?
Make it clear that work is asynchronously proxied in both directions and that
the return code is determined only by whether the initial work is proxied.