|
1 | 1 | GRPC implementation and test
|
2 |
| -============================ |
3 | 2 |
|
4 | 3 | NOTE: files in `src/` are shared with the GRPC project, and maintained there
|
5 | 4 | (any changes should be submitted to GRPC instead). These files are copied
|
@@ -39,4 +38,64 @@ For Bazel users:
|
39 | 38 |
|
40 | 39 | ```shell
|
41 | 40 | $bazel test tests/...
|
42 |
| -``` |
| 41 | +``` |
| 42 | + |
| 43 | +## C++ Callback API Generation |
| 44 | + |
| 45 | +FlatBuffers gRPC C++ code generation now optionally supports the modern gRPC Callback API. |
| 46 | + |
| 47 | +To enable generation of a `CallbackService` skeleton alongside the existing `Service` and async mixins, invoke `flatc` with both `--grpc` and `--grpc-callback-api`: |
| 48 | + |
| 49 | +```shell |
| 50 | +flatc --cpp --grpc --grpc-callback-api your_service.fbs |
| 51 | +``` |
| 52 | + |
| 53 | +This adds (guarded by `#if defined(GRPC_CALLBACK_API_NONEXPERIMENTAL)`) a class: |
| 54 | + |
| 55 | +```cpp |
| 56 | +class YourService::CallbackService : public ::grpc::Service { /* reactor virtuals */ }; |
| 57 | +``` |
| 58 | +
|
| 59 | +Each RPC shape maps to the appropriate reactor return type: |
| 60 | +
|
| 61 | +- Unary -> `::grpc::ServerUnaryReactor*` Method(...) |
| 62 | +- Client streaming -> `::grpc::ServerReadReactor<Request>*` |
| 63 | +- Server streaming -> `::grpc::ServerWriteReactor<Response>*` |
| 64 | +- Bidi streaming -> `::grpc::ServerBidiReactor<Request, Response>*` |
| 65 | +
|
| 66 | +Default generated implementations return `nullptr`; override in your derived class and return a reactor instance you manage (see gRPC docs for lifecycle patterns). |
| 67 | +
|
| 68 | +If your gRPC library predates the stable callback API macro, the code inside the guard will be skipped (no breaking changes). Ensure you build against a recent gRPC (1.38+; verify current minimum in grpc repo) to use this feature. |
| 69 | +
|
| 70 | +### Client Callback Stubs |
| 71 | +
|
| 72 | +When `--grpc-callback-api` is supplied, the generated C++ client stub gains native callback / reactor based async methods in addition to the existing synchronous / generic async flavors, guarded by the same macro. For each RPC named `Foo`: |
| 73 | +
|
| 74 | +Unary: |
| 75 | +
|
| 76 | +``` |
| 77 | +void async_Foo(::grpc::ClientContext*, const Request&, Response*, std::function<void(::grpc::Status)>); |
| 78 | +void async_Foo(::grpc::ClientContext*, const Request&, Response*, ::grpc::ClientUnaryReactor*); |
| 79 | +``` |
| 80 | +
|
| 81 | +Client streaming: |
| 82 | +
|
| 83 | +``` |
| 84 | +::grpc::ClientWriteReactor<Request>* async_Foo(::grpc::ClientContext*, Response*, ::grpc::ClientWriteReactor<Request>*); |
| 85 | +``` |
| 86 | +
|
| 87 | +Server streaming: |
| 88 | +
|
| 89 | +``` |
| 90 | +::grpc::ClientReadReactor<Response>* async_Foo(::grpc::ClientContext*, const Request&, ::grpc::ClientReadReactor<Response>*); |
| 91 | +``` |
| 92 | +
|
| 93 | +Bidirectional streaming: |
| 94 | +
|
| 95 | +``` |
| 96 | +::grpc::ClientBidiReactor<Request, Response>* async_Foo(::grpc::ClientContext*, ::grpc::ClientBidiReactor<Request, Response>*); |
| 97 | +``` |
| 98 | +
|
| 99 | +These map directly onto the native gRPC callback API factories (e.g. `CallbackUnaryCall`, `ClientCallbackWriterFactory::Create`, etc.) and do not spawn threads. Override the appropriate reactor callbacks per gRPC's documentation to drive I/O. |
| 100 | +
|
| 101 | +If your build uses an older gRPC lacking the non-experimental macro, these symbols will not be emitted, preserving backwards compatibility. |
0 commit comments