Documentation improvements about tarpc HOT 7 OPEN

Is it still true that services have to be Clone when using FutureService? As far as I can tell, the tokio event-loop will only handle one event internally at a time, and so the service won't need to be cloned?

from tarpc.

To be honest, I don't know why anymore! the tokio_service::Service trait used to have a Send bound, which meant services needed to either be Sync (and wrapped in an Arc) or Clone, and the latter is a generalization of the former. However, I believe the Send bound was removed from Service so this all needs to be revisited. This is one of the things I want to sort out before the next release, and I really want to ship it this week, so stay tuned (or feel free to investigate it independently; PRs always welcome).

from tarpc.

Currently, this is still true. Some of this code needs to be cleaned up -- for instance, there's a Send bound on FutureService that only exists on the off chance the user wants to start the service via a reactor::core::Remote (a Handle wouldn't require Send). So the bottom line is there is work to do here, but I think if you just wrap your service in an Rc for now it should be fine.

from tarpc.

Hmm, why is that (that Clone is necessary that is)? Is it fundamental? If not, is there a chance that FutureService methods might start taking a &mut self in the future?

from tarpc.

We briefly discussed this a while ago but I can't find the discussion right now. I believe from that discussion that it wasn't particularly tied to FutureService though?

from tarpc.

(btw, let's move this conversation to #86)

from tarpc.

Just leaving a note that we also ought to include a generated service somewhere so that the docs contain an easy-to-reference list of things like methods of FutureService.

from tarpc.