4dff0ee48a
Internal bug b/170934515 In some cases, calling CQ::Next will return true without passing up a new tag value, which is very much illegal. My expectation is that this is due to messing up between SHUTDOWN and TIMEOUT in lower layer code that doesn't particularly matter much to most callers, but was being erroneously checked here. |
||
|---|---|---|
| .. | ||
| security | ||
| README.md | ||
| async_generic_service.h | ||
| async_stream.h | ||
| async_unary_call.h | ||
| byte_buffer.h | ||
| call.h | ||
| call_hook.h | ||
| call_op_set.h | ||
| call_op_set_interface.h | ||
| callback_common.h | ||
| channel_interface.h | ||
| client_callback.h | ||
| client_context.h | ||
| client_interceptor.h | ||
| client_unary_call.h | ||
| completion_queue.h | ||
| completion_queue_tag.h | ||
| config.h | ||
| config_protobuf.h | ||
| core_codegen.h | ||
| core_codegen_interface.h | ||
| create_auth_context.h | ||
| delegating_channel.h | ||
| grpc_library.h | ||
| intercepted_channel.h | ||
| interceptor.h | ||
| interceptor_common.h | ||
| message_allocator.h | ||
| metadata_map.h | ||
| method_handler.h | ||
| method_handler_impl.h | ||
| proto_buffer_reader.h | ||
| proto_buffer_writer.h | ||
| proto_utils.h | ||
| rpc_method.h | ||
| rpc_service_method.h | ||
| serialization_traits.h | ||
| server_callback.h | ||
| server_callback_handlers.h | ||
| server_context.h | ||
| server_interceptor.h | ||
| server_interface.h | ||
| service_type.h | ||
| slice.h | ||
| status.h | ||
| status_code_enum.h | ||
| string_ref.h | ||
| stub_options.h | ||
| sync.h | ||
| sync_stream.h | ||
| time.h | ||
README.md
Welcome to include/grpcpp/impl/codegen
Why is this directory here?
This directory exists so that generated code can include selected files upon
which it depends without having to depend on the entire gRPC C++ library. This
is particularly relevant for users of bazel, particularly if they use the
multi-lingual proto_library target type. Generated code that uses this target
only depends on the gRPC C++ targets associated with these header files, not the
entire gRPC C++ codebase since that would make the build time of these types of
targets excessively large (particularly when they are not even C++ specific).
What should user code do?
User code should not include anything from this directory. Only generated code
and gRPC library code should include contents from this directory. User code
should instead include contents from the main grpcpp directory or its
accessible subcomponents like grpcpp/support. It is possible that we may
remove this directory altogether if the motivations for its existence are no
longer strong enough (e.g., if most users migrate away from the proto_library
target type or if the additional overhead of depending on gRPC C++ is not high).