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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
