##// END OF EJS Templates
rust: pure Rust lazyancestors iterator...
rust: pure Rust lazyancestors iterator This is the first of a patch series aiming to provide an alternative implementation in the Rust programming language of the _lazyancestorsiter from the ancestor module. This iterator has been brought to our attention by the people at Octobus, as a potential good candidate for incremental "oxydation" (rewriting in Rust), because it has shown performance issues lately and it merely deals with ints (revision numbers) obtained by calling the index, whih should be directly callable from Rust code, being itself implemented as a C extension. The idea behind this series is to provide a minimal example of Rust code collaborating with existing C and Python code. To open the way to gradually rewriting more of Mercurial's Python code in Rust, without being forced to pay a large initial cost of rewriting the existing fast core into Rust. This patch does not introduce any bindings to other Mercurial code yet. Instead, it introduces the necessary abstractions to address the problem independently, and unit-test it. Since this is the first use of Rust as a Python module within Mercurial, the hg-core crate gets created within this patch. See its Cargo.toml for more details. Someone with a rustc/cargo installation may chdir into rust/hg-core and run the tests by issuing: cargo test --lib The algorithm is a bit simplified (see details in docstrings), and at its simplest becomes rather trivial, showcasing that Rust has batteries included too: BinaryHeap, the Rust analog of Python's heapq does actually all the work. The implementation can be further optimized and probably be made more idiomatic Rust.

File last commit:

r40008:7a0ffdd4 default
r40307:dbc28c91 default
Show More
attachio.rs
97 lines | 3.6 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 futures::{Async, Future, Poll};
use std::io;
use std::os::unix::io::AsRawFd;
use tokio_hglib::{Client, Connection};
use tokio_hglib::codec::ChannelMessage;
use tokio_hglib::protocol::MessageLoop;
use super::message;
use super::procutil;
/// Future to send 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.
///
/// If the stderr is omitted, it will be redirected to the stdout. This
/// allows us to attach the pager stdin to both stdout and stderr, and
/// dispose of the client-side handle once attached.
#[must_use = "futures do nothing unless polled"]
pub struct AttachIo<C, I, O, E>
where C: Connection,
{
msg_loop: MessageLoop<C>,
stdin: I,
stdout: O,
stderr: Option<E>,
}
impl<C, I, O, E> AttachIo<C, I, O, E>
where C: Connection + AsRawFd,
I: AsRawFd,
O: AsRawFd,
E: AsRawFd,
{
pub fn with_client(client: Client<C>, stdin: I, stdout: O, stderr: Option<E>)
-> AttachIo<C, I, O, E> {
let msg_loop = MessageLoop::start(client, b"attachio");
AttachIo { msg_loop, stdin, stdout, stderr }
}
}
impl<C, I, O, E> Future for AttachIo<C, I, O, E>
where C: Connection + AsRawFd,
I: AsRawFd,
O: AsRawFd,
E: AsRawFd,
{
type Item = Client<C>;
type Error = io::Error;
fn poll(&mut self) -> Poll<Self::Item, Self::Error> {
loop {
let (client, msg) = try_ready!(self.msg_loop.poll());
match msg {
ChannelMessage::Data(b'r', data) => {
let fd_cnt = message::parse_result_code(data)?;
if fd_cnt == 3 {
return Ok(Async::Ready(client));
} else {
return Err(io::Error::new(io::ErrorKind::InvalidData,
"unexpected attachio result"));
}
}
ChannelMessage::Data(..) => {
// just ignore data sent to uninteresting (optional) channel
self.msg_loop = MessageLoop::resume(client);
}
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 = client.as_raw_fd();
let ifd = self.stdin.as_raw_fd();
let ofd = self.stdout.as_raw_fd();
let efd = self.stderr.as_ref().map_or(ofd, |f| f.as_raw_fd());
procutil::send_raw_fds(sock_fd, &[ifd, ofd, efd])?;
self.msg_loop = MessageLoop::resume(client);
}
ChannelMessage::InputRequest(..) | ChannelMessage::LineRequest(..) |
ChannelMessage::SystemRequest(..) => {
return Err(io::Error::new(io::ErrorKind::InvalidData,
"unsupported request while attaching io"));
}
}
}
}
}