You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This proposal assumes that the execution context is only required in the RpcHandler and derived classes.
Idea / Proposal:
It should be possible to remove the execution context entirely from the base class and add it specifically to the classes deriving from RpcHandler. User specified handlers (classes derived from RpcHandler) are registered through the builder as
server_builder.RegisterHandler<MyRpcHandler>();
Since we already need to explicitly specify the derived class (MyRpcHandler), we should be able to implement ::RegisterHandler as if it were a factory function like make_unique. The new call would become:
// would support multiple parameters or none, identical to make_unique
server_builder.RegisterHandler<MyRpcHandler>(my_rpc_handler_ctor_param1);
Advantages:
Less code in the async_grpc library.
The user would be fully in charge of any kind of synchronization which would minimize the libraries' responsibilities.
The user could use value semantics, when no sharing of the context were required. This is what is typically suggested for multi-threading scenarios.
At this point in time, I just wanted to drop the idea.
Regards,
Hauke
The text was updated successfully, but these errors were encountered:
Hi,
this is again a feature request / generalization.
Assumptions:
This proposal assumes that the execution context is only required in the RpcHandler and derived classes.
Idea / Proposal:
It should be possible to remove the execution context entirely from the base class and add it specifically to the classes deriving from RpcHandler. User specified handlers (classes derived from RpcHandler) are registered through the builder as
Since we already need to explicitly specify the derived class (MyRpcHandler), we should be able to implement ::RegisterHandler as if it were a factory function like make_unique. The new call would become:
// would support multiple parameters or none, identical to make_unique server_builder.RegisterHandler<MyRpcHandler>(my_rpc_handler_ctor_param1);
Advantages:
At this point in time, I just wanted to drop the idea.
Regards,
Hauke
The text was updated successfully, but these errors were encountered: