On 04/25/2013 03:46 PM, Brian Anderson wrote:
On 04/25/2013 12:09 PM, Graydon Hoare wrote:
and so forth on other types. Then your file conditions would look like:
condition! {
no_such_file : Path -> FileStream;
}
and
condition! {
write_error : (libc::fd_t, libc::errno_t) -> FileStream;
}
I think the idea here is that you could take your open file handle and
possibly put it into a new FileStream. In that case presumably it
would be the condition handler's responsibility to close the file
handle, so it would need to be wrapped in some RAII.
The main I/O implementation will not be dealing in file descriptors
though, it will be using boxed types defined in the `rtio` module that
wrap Rust uv handles that wrap native uv handles, none of which should
be exposed in the public interface. A condition that exposes C types
is not appropriate there. Furthermore, if we intend for the 'native'
and uv implementations to be interchangeable then they must raise the
same conditions. A generic write error condition could be more like:
This doesn't necessarily have to be the case, actually, depending on
which types need to be interchangeable. This is how the I/O types relate
(with names adjusted for clarity)
mod rt {
// The internal runtime I/O interface
mod rtio {
trait RtTcpStream;
}
// The internal interface as implemented for uv
mod uvio {
impl RtTcpStream for UvTcpStream;
}
// The internal interface as implemented for the native (fd,
socket) types
mod nativertio {
impl RtTcpStream for fd_t;
}
// The public I/O interface
mod io {
trait TcpStream;
// The public interface as implemented for the runtime private
interface
impl TcpStream for ~RtTcpStream;
mod native {
// The public interface as implemented for the native (fd,
socket) types
impl TcpStream for fd_t;
}
}
}
The main TCP implementation, `TcpStream for ~RtTcpStream`, will delegate
to whatever boxed RtTcpStream it is given. Because TcpStream is
responsible for raising conditions, then you can configure the scheduler
to provide you with either uv-based or native implementations and you
will get the same conditions raised.
It's only if you want to replace one implementation of the public
interface for another that you need to worry about whether they raise
the same conditions - and that may not be a real requirement.
Of course, with an error handling mechanism that lets you replace any
Stream with a proxy, then all bets are off and you can end up in
situations where unexpected conditions are being raised.
-Brian
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
