Sure, we can call it a generalization of select. But, (assuming you mean posix select()) they wouldn't be limited to fd's, could be more granular (not just "ready for read/write/error"), and they compose better.
Also, if we could find a way to rope off the buffers, I/O would place data directly into the user buffer, thus avoiding one data copy and the read() or write() call, which normally would be needed after a select(). On Wed, Jan 29, 2014 at 4:53 PM, Kevin Ballard <ke...@sb.org> wrote: > On Jan 29, 2014, at 4:16 PM, Vadim <vadi...@gmail.com> wrote: > > > > > On Wed, Jan 29, 2014 at 3:55 PM, Kevin Ballard <ke...@sb.org> 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 Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
