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
