mirror of https://github.com/grpc/proposal.git
66 lines
2.8 KiB
Markdown
66 lines
2.8 KiB
Markdown
L24: C++ Extensible api
|
|
-----------------------
|
|
* Author(s): makdharma
|
|
* Approver: vjpai
|
|
* Status: Draft
|
|
* Implemented in: https://github.com/grpc/grpc/pull/14517
|
|
* Last updated: Feb 26, 2018
|
|
* Discussion at: https://groups.google.com/forum/#!topic/grpc-io/LVpKsQ4CaFg
|
|
|
|
## Abstract
|
|
|
|
This proposal will enable extending functionality of GRPC C++ API by removing
|
|
the `final` keyword and making some class methods `virtual`. It will allow
|
|
alternate implementations of the API by that subclass.
|
|
|
|
## Background
|
|
|
|
Most GRPC C++ API classes are currently marked `final`. The rationale is that
|
|
having virtual methods might have adverse memory size and performance impact.
|
|
Additionally, adding `final` to public API classes later on would break existing
|
|
implementations that use classes derived from public API. Hence it is better and
|
|
safer to mark classes `final` unless there's a reason to make them extensible.
|
|
|
|
### Related Proposals:
|
|
|
|
## Proposal
|
|
|
|
* Remove `final` keyword from all public API classes.
|
|
* Move a subset of current private methods to protected. See the implementation
|
|
PR for currently defined subset.
|
|
* Add protected getters/setters for a subset of private member variables. See
|
|
the implementation PR for currently defined getters/setters.
|
|
* Mark core methods to `virtual`, so the functionality can be extended.
|
|
* Each such change should go through thorough performance evaluation and should not
|
|
be accepted if there is any observed performance degradation.
|
|
* Do this work in stages. Begin with Server, ServerBuilder, and CompletionQueue
|
|
classes, and extend to other classes as needed.
|
|
|
|
|
|
## Rationale
|
|
|
|
The original rationale for keeping methods private and classes non-extensible
|
|
has not held true. See https://github.com/grpc/grpc/pull/14359 for details of
|
|
performance eval in the extreme case. Meanwhile the `final` classes and
|
|
non-virtual methods preclude any experimentation with implementation. This
|
|
proposal will allow extending and experimenting with different server, client,
|
|
and support structure implementations.
|
|
|
|
The performance impact of removing `final` from all public
|
|
API classes was not measurable. Impact of adding `virtual` was noticable in
|
|
case of Inproc transport microbenchmarks and only for 256K byte messages.
|
|
However, this is a extreme case where virtual was added everywhere, which is not
|
|
the intention behind this proposal. The more realistic case is seen in
|
|
performance results of PR https://github.com/grpc/grpc/pull/14517, which shows
|
|
the impact of both adding `virtual` and removing `final` for a few
|
|
important classes is negligible.
|
|
|
|
|
|
## Implementation
|
|
|
|
The proposed implementation is in PR https://github.com/grpc/grpc/pull/14517.
|
|
It is limited in scope. It doesn't change every public class and method, but it
|
|
gives enough extensibility to experiment with alternate implementations.
|
|
|
|
## Open issues (if applicable)
|