The original pipe implementation made a few assumptions:
* it should be used outside of arenas, implying allocation was expensive
* pipes would be fairly deep
With our expected implementation of the filter stack, pipes will max out at one to three stages, and so optimizations enabled by Filter seem to be actual pessimizations for our usual case.
Additionally we'll be operating inside of arenas and consequently memory allocation can be trivially cheap - and in doing so we can enable a far simpler implementation.
Co-authored-by: ctiller <ctiller@users.noreply.github.com>
* WIP
* introduce XdsResourceType API and change Listener parsing to use it
* converted RouteConfig parsing
* convert cluster and endpoint parsing
* cleanup
* clang-format
* attempt to work around compiler problems
* move XdsResourceType to its own file, and move endpoint code out of XdsApi
* move cluster parsing to its own file
* move route config parsing to its own file
* move listener parsing to its own file
* clang-format
* minor cleanup
* plumbed XdsResourceType throughout XdsClient
* a bit of cleanup
* more cleanup
* construct full resource names before calling XdsApi::CreateAdsRequest()
* remove some unneeded code
* clean up includes and have XdsResourceType initialize the upb symtab
* more cleanup of unnecessary code
* more cleanup
* update comment
* clang-format
* add missing virtual dtor
* fix build
* remove comment
* add missing virtual dtor
* introduce XdsResourceType API and change Listener parsing to use it
* converted RouteConfig parsing
* convert cluster and endpoint parsing
* cleanup
* clang-format
* attempt to work around compiler problems
* move XdsResourceType to its own file, and move endpoint code out of XdsApi
* move cluster parsing to its own file
* move route config parsing to its own file
* move listener parsing to its own file
* clang-format
* minor cleanup
* remove comment
* add missing virtual dtor
* Fix status code for resource exhaustion
* Revert "Revert "Move a bunch of slice typed metadata to new system (#28107)" (#28208)"
This reverts commit 7717587063.
* fix test
* Revert "Revert "user-agent metadata trait, also: grpc_core::Slice is born (#27770)" (#28108)"
This reverts commit 89d08dad9d.
* will it blend
* will it blend
* will it blend
* lcnagfmt
* sanity
* will it blend
* sleep @ end
* will it blend
* Revert "sleep @ end"
This reverts commit d6bca8ed3d.
* review feedback
* review feedback
* Check if memory owner available prior to polling it
The transport may drop the memory owner during its destruction sequence
* tcp_fix
* Revert "Revert "New resource quota integration (#27643)" (#28014)"
This reverts commit 0ea2c37263.
* clang-format
* fix-path
* fix
* Rename the source files for ChannelArgsEndpointConfig
Previous naming was non-descript
* generate_projects
* add missing file to BUILD, and generate_projects.sh
* correct include guards
* Reintroduce the EventEngine default factory
An application can provide an EventEngine factory function that allows
gRPC internals to create EventEngines as needed. This factory would be
used when no EventEngine is provided for some given channel or server,
and where an EventEngine otherwise could not be provided by the
application. Note that there currently is no API to provide an
EventEngine per channel or per server.
I've also deleted some previous iterations on global EventEngine and
EventEngine factory ideas. This new code lives in a public API, and
coexists with iomgr instead of being isolated to an EventEngine-specific
iomgr implementation.
* add proper namespaces, and fix description
* put factory functions in their own file (for replaceability)
* add synchronization
* generate_projects.sh
* extract event_engine_base and event_engine_factory targets
Also separate iomgr/event_engine files in the BUILD, with comments
* gpr_platform
* move all EE factory declarations to event_engine_base
Makes internal hackery easier.
* add missing deps
* reorder dep alphabetically
* comment style change
* [BinderTransport] Avoid depending on NdkBinder at compile time
We would like to make it possible to use BinderTransport in a APK that
has min sdk version lower than 29 (NdkBinder was introduced at 29)
We copies constants and type definitions from Ndk headers, creates a
same name wrapper for every NdkBinder API we use in
grpc_binder::ndk_util namespace.
We will try to load libbinder_ndk.so and resolve the symbol when the
NdkBinder API wrappers are invoked.
* regenerate projects
* Add GRPC_NO_BINDER guard
A config option is provided so user can pass --define=grpc_no_binder=true to bazel, or passing `-DGRPC_NO_BINDER` to compiler to disable the dependency.
* Expose experimental binder transport API
New headers are added
`grpcpp/create_channel_binder.h `: interfaces for creating client
channel
`grpcpp/security/binder_credentials.h`: interfaces for binder server
credentials
`grpcpp/security/binder_security_policy.h`: interfaces for binder
security policy, which is used by both server and client. Individual
security policies are merged into this single header.
Users can now depend on the `grpc++_binder` target to use the headers
listed above.
* Regenerate projects
* [BinderTransport] Create client channel instead of direct channel
In this commit we create a client channel instead of direct channel.
BinderConnector is added to connect subchannel when the user actually
make RPC call using the channel.
BindToOnDeviceServerService() is not required anymore since now the
actual connection is delay until the channel is used.
* Regenerate projects.
Yash Tibrewal
Craig Tiller
Vignesh Babu
krestofur
apolcyn
Jan Tattermusch
hexchain
Mark D. Roth
Esun Kim
ZhenLian
AJ Heller
Ming-Chuan