tokio-stdio - what do you think of this?

[Byron]

In order to get started with Tokio and futures, I decided to make a little command-line tool which should help to interact with crates-io.

The idea of the search subcommand is to allow the user to type anything, and have it request the search result automatically for each keystroke.

As I thought it might be ideal to futurerize the stdio() function of this crate, I put to life the tokio-stdio crate, which might contain no more than said function at first. Ideally, it could be used by this crate too.

Do you think this is feasible at all, or am I on the wrong track?

Note: The problem at hand could already be solved with a futures_cpupool, but in an ideal world, one wouldn't need more than the main thread.

[alexcrichton]

Hm I may not quite be following, but are you basically thinking of having handles (implementing the Io trait) that represent stdin, stdout, stderr? If so I think that's actually quite different from this crate. The tokio-process crate creates handles whereas managing your own stdio means you can't create handles but work with what you have. Unfortunately I know of no way to integrate stdio on Windows with IOCP, so for now a worker/helper thread (the implementation on Windows anyway) generally suffices for asynchronously handling stdio data.

[Byron]

That is exactly what I meant! If stdin/stdout/stderr of the current process could be used with futures, I imagine it would be easier to write asynchronous futurized command-line tools.
To me it appeared setting stdin (for example) to non-blocking would enable that, which seems to be what stdio() does to anything that can be converted into a raw FD.

Asked differently: Is it possible to use stdin/stdout/stderr with tokio core? All implementations of Io seem to be related sockets right now.

It's very likely that I am missing something fundamental here, as I am currently struggling to implement the functionality mentioned in my first comment.

[alexcrichton]

At it's fundamental level this is sort of blocked on tokio-rs/mio#321. You can emulate it today sorta but it needs support at some core level.

In general for small CLI tools and such what you probably want to do is to use channels to communicate to foreign threads. You can have a thread per stdin/stdout/stderr with a futures::sync::mpsc that the main thread communicates with.

[Byron]

Thanks a lot for the heads-up! I will try to use futures::sync::mpsc instead :).