Polling from /dev/tty on macOS

[acidghost]

Polling on /dev/tty on macOS using kqueue is not supported and results in EINVAL .

use mio::unix::SourceFd;
use mio::{Interest, Poll, Token};

use std::fs::File;
use std::os::unix::io::AsRawFd;

fn main() {
    let file = File::open("/dev/tty").unwrap();
    let poll = Poll::new().unwrap();
    let reg = poll.registry();
    let fd = file.as_raw_fd();
    let mut source = SourceFd(&fd);
    reg.register(&mut source, Token(0), Interest::READABLE)
        .unwrap();
}

results into

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }', src/main.rs:14:10

The same problem has been tackled in cpjreynolds/rustty#14 or in libuv/libuv@731adac with select.

I'd be open to contribute to a fix, any suggestion?

[Thomasdezeeuw]

I don't really see how Mio can cleanly support polling from both kqueue and select concurrently. Looking at the commit you linked libuv starts another thread for this, but Mio doesn't start any threads now and I'm not changing that. So I don't really have a suggestion for a good fix, besides that macOS should support /dev/tty in kqueue.

If you do think of something please discuss it here first, because it seems it would become rather involved rather quickly.

[acidghost]

What about having a separate Selector backed by select(2) you can instantiate with something like Poll::new_select (available only under UNIX)?

[Thomasdezeeuw]

If its going to be a completely separate type/implementation it might as well live outside of Mio, at least for now.

[acidghost]

The advantage of having it inside Mio would be the interoperability with other Mio types (e.g. SourceFd) and the possibility to have the same API for Windows applications (i.e. working with Poll and not two different entities).

[Thomasdezeeuw]

The advantage of having it inside Mio would be the interoperability with other Mio types (e.g. SourceFd)

SourceFd is made to be used outside the crate so this argument is not that strong.

and the possibility to have the same API for Windows applications (i.e. working with Poll and not two different entities).

I don't what the tty equivalent is for Windows, but I doubt that IOCP supports it.

In any case, I'm willing to review a change you propose, but I'm not yet convinced it belongs in Mio. I rather not add much more code (> 500 lines) or make the current implementation more complex.

[Thomasdezeeuw]

Closing this as there is little Mio can do here. It's up to macOS to support tty in kqueue.