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

Async via MIO. #37

Closed
wants to merge 248 commits into from
Closed

Async via MIO. #37

wants to merge 248 commits into from

Conversation

tikue
Copy link
Collaborator

@tikue tikue commented May 9, 2016

Noteworthy bits:

  • Not noticeably faster when working with a single client. The main benefit is multiplexing many clients/services on a single event loop.
  • Removed most of the transport abstraction in favor of two enums, Stream and Listener.
  • Provides 3 clients now: Client which is callback based, BlockingClient, and FutureClient.
  • Two servers: BlockingServer which spawns a thread per rpc, and Server which is nonblocking.
  • I was able to remove the *client_methods! macros by ditching the Reply enum. It wasn't required by the protocol since the client always knows what type to expect. We've discussed changing this in the future to return a standard protocol::Reply enum, which covers cases like UnexpectedRequest (if it couldn't be deserialized...etc.).

Other changes

  • Added RpcError and RpcErrorCode.
  • Changed BlockingService trait to have return types of Result<T, tarpc::RpcError>
  • Changed Ctx et al to accept a return value of Result<T, Into<tarpc::RpcError>>.
    • This means you can give it tarpc::Error and it will convert it for you.
      • This means you can chain the result of one service into the return value of a client request.
  • Added an RpcError variant of tarpc::Error. tarpc uses this to transform tarpc::RpcError into tarpc::Error behind the scenes for the client, to un-nest the result return type so that it isn't tarpc::Result<tarpc::RpcResult<T>>.
  • Added server-side-deserialization-error handling. These are converted into RpcErrors with error code WrongService.
  • Created two global event loops, one for client and one for server. By default, new clients and servers use the global event loop.
  • Removed the shutdown methods on the client and server handles. Event loops now can only be shutdown through the registries.
  • Renamed Server::spawn => Server::listen because it doesn't spawn a thread, and generally has a very small resource footprint.
  • Renamed Client::spawn => Client::connect for similar reasons.
  • Other renames:
    • Client => AsyncClient
    • BlockingClient => SyncClient
    • Server => AsyncServer
    • BlockingServer => SyncServer
  • Added a Debug variant to client and server Dispatcher Actions and fn debug to the registries. This makes it easy to get information about the running dispatchers. Currently only returns the number of handlers running.
  • Moved client fns connect and register into the trait protocol::client::Client. This prevents name collisions with rpcs.
  • Moved service fns listen and register into a trait ServiceExt that's expanded by the service! macro, for the same reason as the previous bullet.
  • Moved __AsyncServer into fn register of ServiceExt to prevent unlikely collisions.
  • Moved Ctx and SendCtx out of the macro and into protocol::server. Instead the macro
    creates a Ctx extension trait that protocol::server::Ctx/SendCtx impl.
  • Replaced Ctx::rpc finisher methods with a single Ctx::reply method, and made Ctx generic
    over the reply type, i.e. the ctx arg type to the service fns is now Ctx<Reply>.
  • Added a CachedPool for use by SyncService. It is a growable thread pool whose idle threads expire on a configurable timer.
    • Can also configure the minimum number of threads to keep around (so that it doesn't always expire to 0) and the maximum number of threads to ever spawn.
  • Support for more transports.
    • Unix sockets
    • Pipes (stdin/stdout)

Closes #38

tikue added 30 commits April 28, 2016 02:35
…tten.

Also, don't remove writable() from EventSet unless there really is nothing left to write.
Making the client type-agnostic enables the Dispatcher to more easily group together multiple clients. It should be relatively easy to build a type-safe abstraction on top of them.
By moving type params from ClientHandle struct => ClientHandle::rpc method.
So that it can be used by both client and server.
Almost always, I prefer early returns.
But in this case I think it's cleaner
this way. I don't really know why.
Strangely, 2^18 is quite a bit faster than 2^17.
So that it can compile on windows.
The first 16 bytes are the id and len.
This allows us to cut down reading from 3 states to two states, because the id and message
can be read together.
"RPC" stands for "Remote Procedure Call," a function call where the work of
producing the return value is being done somewhere else. When an rpc function is
invoked, behind the scenes the function contacts some other process somewhere
and asks them to compute the function instead. The original function then
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: s/compute/evaluate

@googlebot
Copy link
Collaborator

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

@tikue
Copy link
Collaborator Author

tikue commented Jul 10, 2016

I authored these commits

@tikue
Copy link
Collaborator Author

tikue commented Aug 23, 2016

Closing in favor of #44

@tikue tikue closed this Aug 23, 2016
@tikue tikue deleted the async branch September 16, 2016 23:22
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

Successfully merging this pull request may close these issues.

5 participants