Also begin to eliminate `CallContext` in favor of just exposing `Call` - ultimately there's not really a need to introduce two types here, so I'm going to wind that idea back over a few PRs.
I've avoided making this an experiment as the changes required were quite structural.
Closes#36477
This was a concept that I thought we'd need, but as work has continued it's clear that the right api is CallDestination (or variants thereof)
Closes#36226
It looks like we're settling on moving this functionality into the channel itself - so removing the filter makes sense (especially since it had some significant bugs)
Closes#36213
Remove rolled out experiments v3_compression_filter, v3_server_auth_filter; Extend WIP v3_channel_idle_filter for a bit, and extend work_serializer_clears_time_cache until OSS issues with work_serializer_dispatch are resolved.
Closes#36166
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#36070
These two things are different (event engine being a context has nothing to do with the ability to get a default event engine).
Lumping them into the same header means that things that want the context also need to want the default event engine declarations, which in turn pull in CoreConfiguration -- which ultimately means that nothing that is depended on by CoreConfiguration can consume the event engine context, which is undesirable (and causing dependency loops in current work).
Also includes an impressive number of cleanups to `grpc_base` because I ran `fix_build_deps` on that target as part of this.
Closes#36148
This adds the following new targets:
- `channel`: A virtual interface for a channel.
- `legacy_channel`: A channel implementation that supports the filter stack and call v2.
- `channel_create`: A standalone function to create a channel.
- `server_interface`: A base class with a few accessor methods used in surface/call.cc.
- `server`: The actual server implementation.
- `api_trace`, `call_tracer`, `server_call_tracer_filter`, `call_finalization`: These were split out of `grpc_base` to avoid various dependency problems.
- `compression`: This is a combination of the previously existing `compression_internal` target and the compression code that was part of `grpc_base`.
Closes#35924
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#35970
As per gRFC A78 (https://github.com/grpc/proposal/pull/419).
Note that these new metrics are populated only if the `wrr_delegate_to_pick_first` experiment is enabled, which is the case by default.
Closes#35977
, since I did not have permissions to add commits to it. That PR has been verified to work (see the top-level description). This PR just makes the gRPC tests pass (e.g. adding includes, clang formatting).
Closes#34874
This breaks the following pieces out of the `grpc_client_channel` BUILD target:
- backend_metric_parser
- oob_backend_metric
- child_policy_handler
- backup_poller
- service_config_channel_arg_filter
- client_channel_channelz
- client_channel_internal_header
- subchannel_connector
- subchannel_pool_interface
- config_selector
- client_channel_service_config_parser
- retry_service_config_parser
- retry_throttle
The code left in the `grpc_client_channel` target will need more work to pull apart.
Closes#35879
This breaks the following pieces out of the `grpc_base` BUILD target:
- channelz
- call_trace
- dynamic_annotations
- call_combiner
- resource_quota_api
- iomgr
More work is still needed to pull apart the remaining parts of `grpc_base`.
Closes#35846
gRPC has been having the `wrap_memcpy` workaround to handle the breaking change of `memcpy` on glibc 2.14 ([ref1](https://www.win.tue.nl/~aeb/linux/misc/gcc-semibug.html), [ref2](https://stackoverflow.com/questions/35656696/explanation-of-memcpy-memmove-glibc-2-14-2-2-5)). This was necessary to build more portable artifacts which are expected to run on most linux distributions and we manged to have https://github.com/grpc/grpc/pull/5007 years ago for this.
Since we started to use manylinux2010-based docker images for artifacts, however, this became unnecessary since CentOS 6 has glibc 2.12 which is older than 2.14 so it doesn't have memcpy issue, which is another benefit of using manylinux2010.
Superseding https://github.com/grpc/grpc/pull/23385
Changes after the original PR was made; Ruby is using manylinux images (manylinux2014) enabling this change, no more old docker images in our test env.
Closes#35826
This new directory combines code from the following locations:
- src/core/ext/filters/client_channel/lb_policy
- src/core/lib/load_balancing
Closes#35786
This PR:
* adds FD extensions to the public headers
* Adds the query extension interface to EventEngine, Listener, and Endpoint, via a new `Extensible` interface
* Refactors the PosixEventEngine to use the Extensible interface.
Closes#35648
A few improvements to the promise context system (more coming)
Allow subclassed contexts:
If we have multiple different kinds of a base context, allow `GetContext<Derived>()` to mean `down_cast<Derived*>(GetContext<Base>())` everywhere for brevity.
Allow custom context lookup:
For a base context type, allow customization of how that context is looked up.
These two together allow:
1. normalization of activity lookup and context lookup to the same syntax (so we can write `GetContext<Activity>()` everywhere now
2. Party & Activity to share a context, so that anywhere we need to do a party specific operation we can write `GetContext<Party>()->...` and safely know that it's the current activity *and* it's a party.
Closes#35592
A call execution environment for the V3 runtime.
The `CallFilters` class will ultimately be a (private) member of `CallSpine`, and the `StackBuilder` component will be used by a channel when all of the filters it needs are known to allow the call spine to start processing a call.
This is accompanied by a reasonably extensive test suite.
I expect to fine tune semantics, implementation, and tests over the coming weeks/months as we iterate to bring up the rest of the pieces.
Closes#35533
Mark D. Roth
Craig Tiller
Hannah Shi
gRPC Team Bot
AJ Heller
Esun Kim
Yash Tibrewal
Yijie Ma
Vignesh Babu
Alisha Nanda
Matthew Stevenson
Eugene Ostroukhov
ericsalo