Feature request: more transports (was: stdin/stdout transport for IPC)

[sbstp]

The spawner process would act as the server and its children as clients. The child process's stdin and stdout can be treated like a socket. The child process could initiate the connection in its main.

I would use that to build a plugin system that allows live load/reload/unload-ing the plugins.

[tikue]

I'll take a crack at this. It'll probably end up on the async branch, which will get merged into master soon (tm).

[tikue]

To the async branch (tikue/async) I added Client::new(Stream), as well as ServeHandle::accept(Stream) where

enum Stream { 
    Tcp(TcpStream), 
    Pipe(PipeWriter, PipeReader),
}

Let me know if you're able to get it working with that. I haven't tested it at all yet.

[tikue]

Added an example demonstrating the usage of pipes.

[sbstp]

Hey, thanks a lot for the quick reply. This looks good.

One thing I'm unsure about, is how to transform a ChildStdin into a PipeWriter.
For instance, the child process would try to connect to the master process in its main.

fn main() {
     let client = Client::connect((io::stdin(), io::stdout()));
}

But it might be impossible to do with mio. Looking quickly at the Stdin/Stdout structs, it doesn't look like they can be set non-blocking.

[tikue]

I spent a bit of time trying to figure that out last night too. I think the best thing to do would be to file an issue on either the rust or mio repo. I'm kind of the middle man here unfortunately.

[tikue]

@sbstp looks like mio added it a couple weeks ago.

[sbstp]

I've searched very briefly, and it doesn't look like there's an easy, cross platform way of configuring stdio to be unblocking. It behaves a lot like file I/O.

We could write a polyfill using background thread to simulate asynchronous I/O, or abandon the entire idea of using stdio.

[tikue]

@sbstp what about mio's support of it that I just linked?

Edit: ah, it's probably only unix support.

[sbstp]

Looks like I didn't search properly. You can fnctl it like any other file descriptor. That fixes our issues then! Only need a new version of mio.

EDIT: It wouldn't work on Windows because the PipeWriter/PipeReader are only available on unix. It's not a problem for my own uses, but it might be a bother for some.

[tikue]

@sbstp yeah, I just added #[cfg(unix)] to tarpc's pipe and unix socket support.

[tikue]

This feature was lost in the tokio rewrite. I'm not sure how I feel about it now. I do like the simplicity of dealing strictly with TCP, but I realize that there's an opportunity here to be useful to a wider audience. I think I'll continue to leave this issue open, but I don't intend to implement it at this time unless there's significant demand.

[tikue]

Should tarpc be generic over the transport layer (basically Io, or the new AsyncRead + AsyncWrite)? It seems worth considering, though I don't know if the hit to ergonomics is worth it. All clients and servers taking a type parameter seems rough. Maybe it's better to just extend StreamType to support a few more types of streams.

[tikue]

Obsoleted by #199. tarpc is now transport-agnostic.