[rust-dev] Futures in Rust

Kevin Ballard kevin at sb.org
Wed Jan 29 15:55:54 PST 2014


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.

-Kevin

On Jan 29, 2014, at 2:19 PM, Vadim <vadimcn at gmail.com> wrote:

> What event initiates the write?
> 
> 
> On Wed, Jan 29, 2014 at 2:11 PM, Kevin Ballard <kevin at sb.org> wrote:
> This solution will not work for what I need stream splitting for. Namely, I need to be in the middle of reading from a socket when I decide that I need to write. I cannot be waiting on the read future at that time or I won't be able to start writing. And if I don't wait on the read future, I won't know when I have data available.
> 
> -Kevin
> 
> On Jan 29, 2014, at 2:03 PM, Vadim <vadimcn at gmail.com> wrote:
> 
> > After reading about the simultaneous stream reading/writing issue discussed in the last meeting, I want to ask a question:  Maybe it's time to consider using explicitly async I/O and futures?
> >
> > Futures sort of already exist in the libextra, but they still rely on pushing async operation into a separate task.  I wonder if Rust could support in-task asynchronicity.   If we had that, the simultaneous read/write example could be written as:
> >
> >     let buffer1 = [u8, ..1024];
> >     let buffer2 = [u8, ..1024];
> >     ...
> >     let future1 = stream.read(buffer1);
> >     let future2 = stream.write(buffer2);
> >     let combined = wait_any(future1, future2); // new future that resolves once any of its' parameters does
> >     combined.wait(); // wait till the combined future resolves
> >     if future1.is_complete() {
> >         let value = future1.get_result();
> >     }
> >     ...
> > Current proposals, such as stream splitting might work for that particular case, but what about stuff like "read stream with a timeout"?   With futures, that'd be easy - just combine the read future with a timer future similarly to the above.  I am sure there are tons of other useful scenarios that would be simplified with futures.
> >
> > I know that currently there is a problem with preventing un-synchronized access to local resources involved in the async operation.  In my example above, the state of buffers is undefined until async operation is complete, so they should be roped off for the duration.
> > But maybe Rust type system could grow a new type of borrow that prevents all object access while it is in scope, similarly to how iterators prevent mutation of the container being iterated?
> >
> > Vadim
> >
> > _______________________________________________
> > Rust-dev mailing list
> > Rust-dev at mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> 
> 
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140129/3191888e/attachment-0001.html>


More information about the Rust-dev mailing list