What event initiates the write?
On Wed, Jan 29, 2014 at 2:11 PM, Kevin Ballard <ke...@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 <vadi...@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@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
