Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    PeterSP
    @PeterSP
    When you say chomp are you talking about the concept of consuming input, about the chomp parser, about some feature of serde, or something else?
    Tim
    @tikue
    yeah I just mean the general idea of consuming bytes off the wire
    PeterSP @PeterSP nods
    Tim
    @tikue
    is your protocol length-delimited?
    PeterSP
    @PeterSP
    nope :D It's newline-terminated
    (And urlencodes newlines that occur in input)
    Tim
    @tikue
    ah ok, so probably the transport will need to continually read into an internal buffer until it sees a newline
    before calling deserialize()
    since you can't block on reading from the TcpStream in futures
    Tim
    @tikue
    Tokio actually has a lines codec you can reuse for that part: https://github.com/tokio-rs/tokio/blob/master/tokio-codec/src/lines_codec.rs
    So you'd basically start with that codec and then layer on the serialization part
    PeterSP
    @PeterSP
    Nice!
    Tim
    @tikue
    @PeterSP I thought about your protocol yesterday, and one problem is that tarpc requires a transport that implements a multiplexing protocol. So for instance your request would need to be tagged with a request number
    Does your Client assume first request in first response out?
    Tim
    @tikue
    err, of course, one way around that (if your client transport absolutely cannot multiplex) is to open a new connection for each request :o)
    you'd probably want the server side transport to limit itself to reading one request, via take(1) or something
    PeterSP
    @PeterSP
    The service currently expects a new connection per each request I think, using UNIX sockets
    Tim
    @tikue
    ah, in that case, you can just always tag it with id 0 :D
    Hikarakuyo
    @Hikarakuyo_gitlab
    Well is this chat still used?
    Tim
    @tikue
    @Hikarakuyo_gitlab I'm still here
    Yi Wang
    @yiwang
    not sure if I missed any thing, try to run cargo build on master and failed
    % cargo run --bin server
       Compiling tarpc-lib v0.6.0 (/tarpc/rpc)
       Compiling tokio v0.1.22
    error[E0432]: unresolved import `futures::try_ready`
      --> rpc/src/server/mod.rs:21:5
       |
    21 |     try_ready,
       |     ^^^^^^^^^ no `try_ready` in the root
    
    error: cannot determine resolution for the macro `try_ready`
       --> rpc/src/server/mod.rs:337:17
        |
    337 |                 try_ready!(self.as_mut().channel().poll_flush(cx));
        |                 ^^^^^^^^^
        |
        = note: import resolution is stuck, try simplifying macro imports
    
    error[E0437]: type `SinkError` is not a member of trait `Sink`
      --> rpc/src/transport/channel.rs:54:5
       |
    54 |     type SinkError = io::Error;
       |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ not a member of trait `Sink`
    
    error[E0437]: type `SinkError` is not a member of trait `Sink`
      --> rpc/src/transport/mod.rs:86:5
       |
    86 |     type SinkError = S::SinkError;
       |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not a member of trait `Sink`
    
    error[E0220]: associated type `SinkError` not found for `futures_sink::Sink<<Self as transport::Transport>::SinkItem>`
      --> rpc/src/transport/mod.rs:27:47
       |
    27 |     Self: Sink<<Self as Transport>::SinkItem, SinkError = io::Error>,
       |                                               ^^^^^^^^^^^^^^^^^^^^^ associated type `SinkError` not found
    
    error[E0220]: associated type `SinkError` not found for `Self`
      --> rpc/src/transport/channel.rs:68:82
       |
    68 |     fn poll_flush(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Result<(), Self::SinkError>> {
       |                                                                                  ^^^^^^^^^^^^^^^ associated type `SinkError` not found
    
    error[E0220]: associated type `SinkError` not found for `S`
      --> rpc/src/transport/mod.rs:88:67
       |
    88 |     fn start_send(self: Pin<&mut Self>, item: Item) -> Result<(), S::SinkError> {
       |                                                                   ^^^^^^^^^^^^ associated type `SinkError` not found
    
    error[E0220]: associated type `SinkError` not found for `S`
      --> rpc/src/transport/mod.rs:92:82
       |
    92 |     fn poll_ready(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Result<(), S::SinkError>> {
       |                                                                                  ^^^^^^^^^^^^ associated type `SinkError` not found
    
    error[E0220]: associated type `SinkError` not found for `S`
      --> rpc/src/transport/mod.rs:96:82
       |
    96 |     fn poll_flush(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Result<(), S::SinkError>> {
       |                                                                                  ^^^^^^^^^^^^ associated type `SinkError` not found
    
    error[E0220]: associated type `SinkError` not found for `S`
       --> rpc/src/transport/mod.rs:100:82
        |
    100 |     fn poll_close(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Result<(), S::SinkError>> {
        |                                                                                  ^^^^^^^^^^^^ associated type `SinkError` not found
    
    error[E0220]: associated type `SinkError` not found for `futures_sink::Sink<SinkItem>`
      --> rpc/src/transport/mod.rs:48:23
       |
    48 |     S: Sink<SinkItem, SinkError = io::Error>,
       |                       ^^^^^^^^^^^^^^^^^^^^^ associated type `SinkError` not found
    
    error[E0220]: associated type `SinkError` not found for `futures_sink::Sink<SinkItem>`
       --> rpc/src/transport/mod.rs:109:26
        |
    109 |     Self: Sink<SinkItem, SinkError = io::Error>,
        |                          ^^^^^^^^^^^^^^^^^^^^^ associated type `SinkError` not found
    
    error[E0220]: associated type `SinkError` not found for `S`
      --> rpc/src/transport/mod.rs:86:22
       |
    86 |     type SinkError = S::SinkError;
       |                      ^^^^^^^^^^^^ associated type `SinkError` not found
    
    error: aborting due to 13 previous errors
    
    Some errors have detailed explanations: E0220, E0432, E0437.
    For more information about an error, try `rustc --explain E0220`.
    error: Could not compile `tarpc-lib`.
    warning: build failed, waiting for other jobs to finish...
    error: build fail
    Yi Wang
    @yiwang
    cargo update -p futures-preview --precise 0.3.0-alpha.16 fixed it.
    Tim
    @tikue
    @yiwang sorry, I don't seem to be getting gitter notifications ! I haven't been on gitter recently
    Yi Wang
    @yiwang
    I need to figure out how to kill the server
    Tim
    @tikue
    @yiwang nice :)
    @yiwang I could make some suggestions for that. Do you want to kill it from an RPC or from inside the process?
    btw I'd be interested in your opinion of the latest changes on master. I've changed the way rpc services are defined
    Tim
    @tikue
    for shutdown, you could do something like struct LocalNativeServer { running: Arc<AtomicBool> }
    actually I'd probably use futures::future::AbortHandle.
    in this example, shutdown breaks the incoming connections stream but honors existing connections. That may or may not be how you'd want to do it, but should at least give you some ideas
    Bruno Bigras
    @bbigras
    Is it possible to use a Result like this:
    #[tarpc::service]
    pub trait World {
        async fn hello(name: String) -> Result<String, String>;
    }
    I would like the client to get the error
    Bruno Bigras
    @bbigras
    I was able to do it with:
    #[tarpc::service]
    pub trait World {
        async fn hello(name: String) -> Result<String, String>;
    }
    
    impl World for HelloServer {
        type HelloFut = futures::future::BoxFuture<'static, Result<String, String>>;
    
        fn hello(self, _: context::Context, name: String) -> Self::HelloFut {
            something().boxed()
        }
    }
    Tim
    @tikue
    @bbigras yes, definitely :)
    Bruno Bigras
    @bbigras
    thanks. Don't hesitate to tell me if there was a better way than how I did it.
    Tim
    @tikue
    using a result in the definition is idiomatic IMO
    Bruno Bigras
    @bbigras
    thanks
    Tim
    @tikue
    I'd probably recommend returning something that can be programmatically inspected -- like struct Error { code: ErrorCode, message: String }
    Bruno Bigras
    @bbigras
    yeah good idea
    Artem Vorotnikov
    @vorot93

    @tikue I kind of missed

    google/tarpc@41c1aaf

    Tokio is definitely the dominant but not the only executor. For one, there is one offered in futures-rs itself. And it is used by riker, for example.

    https://github.com/riker-rs/riker/blob/master/src/system/system.rs#L49

    Artem Vorotnikov
    @vorot93

    Also

    https://github.com/google/tarpc/issues/243#issuecomment-517066516

    Given that it's an optional feature purely for helper methods, it seems reasonable to be more opinionated about the dependencies used by that feature.

    This includes tying up the tarpc server into a nicely packaged Future without knowing intricate internals of dispatcher and so on. One hell of helper methods! End users are just not going to rewrite these on their own should they opt for runtime crate.

    Tim
    @tikue
    I'm not sure about that. We can always add more runtime agnostic helpers. The fact that this is the route hyper chose is a strong signal to me
    Tim
    @tikue
    Willing to reconsider but at the very least I'd want to hear of a user of a non-tokio runtime
    Artem Vorotnikov
    @vorot93

    Like I said forcing tokio precludes using riker.

    https://gitter.im/riker-rs/Lobby?at=5c5cfe4ddc3f0523cc7aac79

    This does look like a turf war and pissing contest but it is what it is. IMO we should provide support for both runtime and tokio 0.2.

    FWIW this was a very hot topic debated on Rust meetup in Moscow on Friday. People are not very happy with tokio's vendor lock and no one knows how this will pan out.
    Tim
    @tikue
    What about having multiple features -- one per runtime -- and using some macros to prevent a ton of code duplication? The problem with the runtime crate is it's not zero cost. Tying directly to runtimes avoids some additional pointer indirection and thread local access.