Comment 7 for bug 1909861

It appears that pre-uring AIO is being supplanted by io_uring (https://unixism.net/2020/04/io-uring-by-example-part-1-introduction/ and https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-will-revolutionize-programming-in-linux/). AIO has had persistent critiques since it was introduced (e.g., https://lwn.net/Articles/724198/), and as best as I can tell appears to have been tolerated in the absence of anything better until Linux 5.1, which added io_uring.

Asynchronous Linux file I/O is in an unfortunate limbo at the moment, where the ubiquitously supported approach is being displaced quickly enough it's unclear whether it's worth targeting specifically anymore. The usual approach appears to be to use libuv or libevent to abstract over these interfaces, both across Linux kernel versions and operating systems more broadly.

For the BSDs (Open/Free/Net/Dragonfly) and macOS, there's kqueue() with EVFILT_READ, which has been around long enough it can simply be required as part of the condition of supporting those OSes. Except for macOS, these are probably quite niche even within the DC userbase, but since the kqueue() appears to operate similarly across all of them, a single approach should work.

Therefore, to the extent that readMapped() was meant partly to introduce asynchrony even when readDirect() didn't work, the in-principle-better approach would seem still be to drop readMapped() and implement readDirect() for non-Windows OSes using io_uring and/or kqueue(), potentially through existing libraries such as libevent or libuv if appropriate.

Strictly in terms of addressing this bug that you've reported for DC++, I probably wouldn't wait for such steps. Given that DC++ does not officially support any non-Windows platform, it seems fine to use, in your terminology, readAsync with a readUnbuffered fallback, without any readMapped().