tokio-stdio - what do you think of this? #7

Closed
Byron opened this Issue Dec 29, 2016 · 4 comments

Comments

Projects
None yet
2 participants
@Byron

Byron commented Dec 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Dec 29, 2016

Owner

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.

Owner

alexcrichton commented Dec 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Byron

Byron Dec 29, 2016

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.

Byron commented Dec 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Dec 29, 2016

Owner

At it's fundamental level this is sort of blocked on carllerche/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.

Owner

alexcrichton commented Dec 29, 2016

At it's fundamental level this is sort of blocked on carllerche/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

This comment has been minimized.

Show comment
Hide comment
@Byron

Byron Dec 29, 2016

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

Byron commented Dec 29, 2016

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

@Byron Byron closed this Dec 29, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment