[rust-dev] Futures in Rust

Kevin Ballard kevin at sb.org
Wed Jan 29 14:11:45 PST 2014


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



More information about the Rust-dev mailing list