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

Move internals of many C++ Async classes to ref-counted struct #5099

Merged
merged 10 commits into from
Feb 8, 2016

Conversation

vjpai
Copy link
Member

@vjpai vjpai commented Feb 5, 2016

The purpose of this is to reduce the likelihood of races caused in the async code without changing the API. The current situation was that an async operation queued multiple entries on the core completion_queue, only some of which get delivered up to C++. If the entries are processed by different threads, a regular (as opposed to Sneaky) CallOpSet could successfully return control to the application thread from CompletionQueue::Next and thus allow the application to delete the Async class that it belongs to; meanwhile, one of the other (sneaky or regular) CallOpSets might still have work to do on a different thread and could have its object destructed before it is invoked.

vjpai added 3 commits February 5, 2016 13:40
whenever appropriate so as to avoid any unintentional free-before-use
problems.

Potential performance issue: this triggers an additional allocation
for each Async call initiation, along with the cost of ref-counting
shared_ptr . But this is worth it for the additional safety provided
here without any change to the exposed C++ API.
@grpc-kokoro
Copy link

Can one of the admins verify this patch?

1 similar comment
@grpc-kokoro
Copy link

Can one of the admins verify this patch?

@ctiller
Copy link
Member

ctiller commented Feb 5, 2016

Would it be saner to restrict this refactoring to just those stream objects that also contain SneakyOps?

Justification:

  • it's a much smaller diff
  • it's going to be easier to refine that smaller diff to elide the allocation in the future
  • we don't think it's necessary to take the extra allocation without a sneaky op?

@vjpai
Copy link
Member Author

vjpai commented Feb 5, 2016

So, I was working with the idea that we should protect against any
situation where multiple CallOpSet's could be processed in parallel by
different threads. But I guess you are saying that in that situation (when
it's not Sneaky), the user already sees the CQ events for each of those
CallOpSet's and has to act on them. Is that correct?

On Fri, Feb 5, 2016 at 2:04 PM Craig Tiller notifications@github.com
wrote:

Would it be saner to restrict this refactoring to just those stream
objects that also contain SneakyOps?

Justification:

  • it's a much smaller diff
  • it's going to be easier to refine that smaller diff to elide the
    allocation in the future
  • we don't think it's necessary to take the extra allocation without a
    sneaky op?


Reply to this email directly or view it on GitHub
#5099 (comment).

@ctiller
Copy link
Member

ctiller commented Feb 5, 2016

That's correct. And they're obliged to deal with them. I think this is only a problem when we don't show the user what's going on (to simplify API).

with a Sneaky member are in a collection.
@vjpai
Copy link
Member Author

vjpai commented Feb 5, 2016

ok, did that....

@ctiller
Copy link
Member

ctiller commented Feb 5, 2016

Shouldn't CallOpSet::FinalizeResult call SetCollection(nullptr) to clear the reference cycle once the op is done?

@vjpai
Copy link
Member Author

vjpai commented Feb 5, 2016

You're right. I was thinking that most of our accesses had "delete this" on them, but that's not for these struct's at all. Yes, we need to drop the ref ourselves.

@vjpai
Copy link
Member Author

vjpai commented Feb 8, 2016

I believe that this is ready to review

@vjpai
Copy link
Member Author

vjpai commented Feb 8, 2016

... and I believe that all affected test (C++) pass.

@ctiller
Copy link
Member

ctiller commented Feb 8, 2016

LGTM

@nicolasnoble
Copy link
Member

Green enough to merge ?

nicolasnoble added a commit that referenced this pull request Feb 8, 2016
Move internals of many C++ Async classes to ref-counted struct
@nicolasnoble nicolasnoble merged commit e2c7671 into grpc:master Feb 8, 2016
@vjpai vjpai deleted the cpp_races branch February 9, 2016 17:30
@lock lock bot locked as resolved and limited conversation to collaborators Jan 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants