##// END OF EJS Templates
errors: catch urllib errors specifically instead of using safehasattr()...
errors: catch urllib errors specifically instead of using safehasattr() Before this patch, we would catch `IOError` and `OSError` and check if the instance had a `.code` member (indicates `HTTPError`) or a `.reason` member (indicates the more generic `URLError`). It seems to me that can simply catch those exception specifically instead, so that's what this code does. The existing code is from fbe8834923c5 (commands: report http exceptions nicely, 2005-06-17), so I suspect it's just that there was no `urllib2` (where `URLError` lives) back then. The old code mentioned `SSLError` in a comment. The new code does *not* try to catch that. The documentation for `ssl.SSLError` says that it has a `.reason` property, but `python -c 'import ssl; print(dir(ssl.SSLError("foo", Exception("bar"))))` doesn't mention that property on either Python 2 or Python 3 on my system. It also seems that `sslutil` is pretty careful about converting `ssl.SSLError` to `error.Abort`. It also is carefult to not assume that instances of the exception have a `.reason`. So I at least don't want to catch `ssl.SSLError` and handle it the same way as `URLError` because that would likely result in a crash. I also wonder if we don't need to handle it at all (because `sslutil` might handle all the cases). It's now early in the release cycle, so perhaps we can just see how it goes? Differential Revision: https://phab.mercurial-scm.org/D9318

File last commit:

r45240:27fe8cc1 default
r46442:ae00e170 default
Show More
attachio.rs
68 lines | 2.4 KiB | application/rls-services+xml | RustLexer
// Copyright 2018 Yuya Nishihara <yuya@tcha.org>
//
// This software may be used and distributed according to the terms of the
// GNU General Public License version 2 or any later version.
//! Functions to send client-side fds over the command server channel.
use std::io;
use std::os::unix::io::AsRawFd;
use tokio_hglib::codec::ChannelMessage;
use tokio_hglib::{Connection, Protocol};
use crate::message;
use crate::procutil;
/// Sends client-side fds over the command server channel.
///
/// This works as follows:
/// 1. Client sends "attachio" request.
/// 2. Server sends back 1-byte input request.
/// 3. Client sends fds with 1-byte dummy payload in response.
/// 4. Server returns the number of the fds received.
///
/// The client-side fds may be dropped once duplicated to the server.
pub async fn attach_io(
proto: &mut Protocol<impl Connection + AsRawFd>,
stdin: &impl AsRawFd,
stdout: &impl AsRawFd,
stderr: &impl AsRawFd,
) -> io::Result<()> {
proto.send_command("attachio").await?;
loop {
match proto.fetch_response().await? {
ChannelMessage::Data(b'r', data) => {
let fd_cnt = message::parse_result_code(data)?;
if fd_cnt == 3 {
return Ok(());
} else {
return Err(io::Error::new(
io::ErrorKind::InvalidData,
"unexpected attachio result",
));
}
}
ChannelMessage::Data(..) => {
// just ignore data sent to uninteresting (optional) channel
}
ChannelMessage::InputRequest(1) => {
// this may fail with EWOULDBLOCK in theory, but the
// payload is quite small, and the send buffer should
// be empty so the operation will complete immediately
let sock_fd = proto.as_raw_fd();
let ifd = stdin.as_raw_fd();
let ofd = stdout.as_raw_fd();
let efd = stderr.as_raw_fd();
procutil::send_raw_fds(sock_fd, &[ifd, ofd, efd])?;
}
ChannelMessage::InputRequest(..)
| ChannelMessage::LineRequest(..)
| ChannelMessage::SystemRequest(..) => {
return Err(io::Error::new(
io::ErrorKind::InvalidData,
"unsupported request while attaching io",
));
}
}
}
}