Linux version

[bestouff]

Nice job ! I'm opening this issue to have some way of tracking an eventual linux port.

[asomers]

I'm glad to see there's some interest. Might I know how you found out about tokio-file?

[bestouff]

I'm toying with the idea of a very specialized executable (a proto at work, because using rust in production isn't yet possible) involving http, mqtt and files, and that's the missing piece for when I'm reading to jump to tokio. Found it by searching crates.io from time to time.

[mehcode]

I'm working on an end-to-end asynchronous web framework and serving files with non-blocking I/O is something I'm very interested in.

Likewise, I found this by searching around crates.io to see what's available. I'd love to use something like this. My current solution is going to be bringing in futures-cpupool (though I'm still going to have to do this until the rest of Rust's ecosystem is async like Diesel).

[asomers]

@mehcode are you volunteering? It would be possible add Linux support, using libaio instead of POSIX aio, and using eventfd instead of kqueue.

[seunlanlege]

Is there a reference implementation that I can port over?

[asomers]

I'm not sure what you mean by a reference implementation. The way to get Linux support into Tokio-file is to write a mio-libaio crate that will resemble mio-aio, but using Linux's libaio. Libaio is poorly documented, but it does work.