Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Generalize how users pass execution contexts to the server #22

Open
hauke76 opened this issue May 30, 2018 · 0 comments
Open

Comments

@hauke76
Copy link
Collaborator

hauke76 commented May 30, 2018

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant