[rust-dev] Futures in Rust

Vadim vadimcn at gmail.com
Wed Jan 29 14:19:22 PST 2014


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140129/5b5345b3/attachment.html>


More information about the Rust-dev mailing list