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