On 04/27/2013 03:07 AM, Jordi Boggiano wrote:
Take my input with a grain of salt since I'm so new to the language, but
here goes nothing:
I am particularly interested in making sure that common operations are
convenient and don't require a lot of boilerplate. To that end I've been
collecting [aspirational examples] of succinctly written Rust I/O code
using the hypothetical API. The goal will be to turn these into test
cases. I welcome additional examples.
One fairly common (at least to me) case I would like addressed is TCP
reads/writes with timeouts. It's quite common when writing anything
network related that you need to handle timeouts to be able to kill the
connection and retry or abort. If you don't you easily end up with
zombie processes. In the current net::tcp it seems possible using the
raw socket, but not if you use any of the convenience of TcpSocketBuf.
I'm not sure how this would be best implemented, but I just wanted to
raise the issue before it's too late and we have to write lots of
boilerplate task monitoring to have timeouts. Which is ok but a bit hard
on newcomers.
Yes, thank you. This is an important consideration and everything needs
to be cancelable in some way.
A related thing I'm worried about is being able to cancel an I/O
operation by sending a message over a pipe, like
let listener = TcpListener::new(address);
let (port, chan) = stream();
// Wait for either the next incoming connection or a signal to stop
listening
match select(port, listener) {
...
}
I don't know how to do this yet and think it may not be possible for
1.0, considering everything else that needs to be done.
## Error handling
I've spent a lot of time thinking about - and talking to Patrick about -
how I/O should deal with errors (the old `io` doesn't have a consistent
strategy). The [error handling strategy] I'm proposing is intended to
eliminate boilerplate and allow efficient recovery from errors, but it
uses some uncommon patterns.
This seems suboptimal still. Reading your [error handling] example, I
wonder if this is really better than traditional exceptions that would
break the execution after the failed `new` call. Now this might not be
practical to implement in rust, so I'll skip over that and assume
conditions are good.
You say that both `new` and `write_line` will raise a condition in this
case, but that means `error` at the end contains the second condition,
which probably would have a message like "could not write in a null
file" or something. While the message that interests us, for debugging
or printing out to the user, is the first one "could not open file
because of X".
I fear that in the end to be able to handle and report errors properly
one would have to write so much condition handling boilerplate that
simply relying on multiple return values à la Go might be best.
[error handling]
https://github.com/brson/rust/blob/io/src/libcore/rt/io/mod.rs#L155-164
## Close
Do we need to have `close` methods or do we depend solely on RAII for
closing streams?
I would say yes, because sometimes you really need to release a file to
be able to do other things with it (especially on windows which likes to
lock files for various reasons).
## Constructor options
I am considering defining `open` more like `fn open:<S: OpenSpec>(spec:
S)`, then implementing `OpenSpec` for e.g. `&str`, `Path`, `(Path,
FileFlags, FileAccess), `Url`, etc.
Does this seem reasonable?
Feels weird to have str implement something specific to another module,
but if there is no other way it sounds more user friendly than a
gazillion open_* methods.
A few more comments on other things:
- Streams are great, and the ability to register new stream protocol
handler for "foo:..." urls would indeed be a big plus.
Yes, it would be very cool but so far I don't know how to do this
transparently since there's no life before main in Rust.
- File vs FileStream, you could have a File (FileStream) and a FileInfo
for the info stuff, since the latter is less commonly used.
I like that idea.
- open vs connect, I'd say open. Opening a connection sounds ok,
connecting a file sounds awkward.
Cheers
Thanks for the feedback.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
