On Jan 29, 2014, at 4:16 PM, Vadim <[email protected]> wrote:
>
>
>
> On Wed, Jan 29, 2014 at 3:55 PM, Kevin Ballard <[email protected]> wrote:
> Any number of things.
>
> The use case here is an interactive protocol where writes go in both
> directions, and can be initiated in response to external events. The classic
> example is an IRC bot. The server can send a message at any time, so the IRC
> bot needs to be constantly reading, but writes back to the socket are not
> necessarily initiated directly in response to reads, they may be initiated
> due to asynchronous operations, or keyboard input at the terminal, or any
> number of other external stimuli.
>
> In this case you'd be waiting on futures from those external events as well.
> I am assuming that all of I/O would be future-ized, not just TCP streams.
"external events" does not necessarily mean I/O. It could also mean some
asynchronous computation inside the app.
And if you're going to try and claim that this can be represented by futures
too in this same scheme, well, it pretty much sounds like you're reinventing
the generic Select. Or perhaps I should call it a run loop.
-Kevin
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
