CompletionQueue DoThenAsyncNext#13084
Conversation
|
|
There was a problem hiding this comment.
can we do:
template <typename T, typename F>
NextStatus DoThenAsyncNext(F&& f, /* ... rest of args ... */) {
// ... rest of code
}and avoid unnecessarily instantiating a std::function (since this is not for free, and lambda's pretty much are)
There was a problem hiding this comment.
similarly here, and hoist the implementation into the header
There was a problem hiding this comment.
Can we make a small class to handle the TLS cache here... constructor calls grpc_prepare... destructor does the cleanup (and could be in a cc file out of line since it's sufficiently complex)
There was a problem hiding this comment.
Variable names should be lower case
There was a problem hiding this comment.
== nullptr would be better here (for new code)
|
|
Addressed comments from ctiller's review. |
|
|
1 similar comment
|
There was a problem hiding this comment.
F&&
(we want to be able to pass l- and r- values here)
There was a problem hiding this comment.
Maybe make this a private member class of CompletionQueue (public names are forever)... If we need to we can promote later
test/cpp/qps/client_async.cc
Outdated
There was a problem hiding this comment.
F&& change should allow this to be passed to DoThen directly, which would be preferable
|
Addressed feedback/added unit tests. |
|
|
|
|
include/grpc/grpc.h
Outdated
There was a problem hiding this comment.
grpc_cq_tls_cache_prepare to be more consistent with naming throughout the core API (object name first, then action verb). Additionally, since this is API, I would suggest not using "tls" because of abbreviation-ambiguity. (Note that C++ style guide doesn't like abbreviations.) Please call it grpc_cq_thread_local_cache or grpc_thread_local_cq or something like that
There was a problem hiding this comment.
Additionally, even though these are experimental, please document the parameters and return values (more important for flush than prepare)
include/grpc/grpc.h
Outdated
There was a problem hiding this comment.
Please add a comment above indicating what is the purpose of these TLS (implementation of cq thread-local cache, etc)
There was a problem hiding this comment.
Since the cache implementation here is essentially a single element in a single CQ, these variable names are misleading. Can you call it g_cached_event and g_cached_cq or something like that? I would also add a comment saying that in the current implementation, only 1 event for 1 CQ is ever cached at a thread, to make it clear that this is the current cache characteristic. This is quite fine for the use case, but the name "cache" suggests the possibility of more than that (which is fine from an API perspectiv, since the current API does not preclude that in the unlikely event that it is ever desired in the future.)
|
I've requested changes, but they're mostly cosmetic. |
|
Addressed comments |
|
|
|
|
grpc.def
Outdated
There was a problem hiding this comment.
Please rename to grpc_thread_local_completion_queue_cache_init because it is more rhythmic (can be sung to the tune of Supercalifragilisticexpialidocious)
|
|
|
|
|
Adds an experimental function to C++ Completion Queues DoThenAsyncNext. It allows users to pass a lambda to be executed before the AsyncNext. If the lambda triggers a completion event, it is guaranteed to be delivered on the AsyncNext call.