[rust-dev] Futures in Rust

Vadim vadimcn at gmail.com
Wed Jan 29 17:52:44 PST 2014

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 <kevin at sb.org> wrote:

> On Jan 29, 2014, at 4:16 PM, Vadim <vadimcn at gmail.com> wrote:
> On Wed, Jan 29, 2014 at 3:55 PM, Kevin Ballard <kevin at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140129/fdaafa64/attachment.html>

More information about the Rust-dev mailing list