https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
--- Comment #26 from Janne Blomqvist <jb at gcc dot gnu.org> --- I though I wrote somewhere why I gave up on this, after thinking a lot about the problem in general. However, I can't find my writeup now, so I'll add a short version here so that others who are interested in this problem may benefit. So, to begin with, non-blocking socket I/O is widely used on Linux and works well (select(), epoll() etc.). However, here we're talking about file IO, not sockets. For file IO, the non-blocking socket programming model doesn't work; files are always considered "fast" devices and thus always return ready if you try to poll them. Thus, asynchronous I/O. The choices are roughly: 1) Linux native AIO: syscalls like io_submit() etc. This however works only on files opened with O_DIRECT, and all I/O must be 512-byte aligned. So clearly this disqualifies this solution for something general purpose like Fortran AIO. 2) POSIX AIO (aio_read() etc.). This, in principle, could work. Except for 1) It uses signals for reporting completions, which is horrible. Also, some may consider it bad form if libgfortran uses (limited) signal numbers for its internal use, preventing applications from using them. 2) On Linux, glibc implements POSIX AIO using a userspace thread pool, with the further restriction that only a single outstanding I/O per file descriptor is possible (which may or may not matter for Fortran AIO). 3) Do it yourself with a thread pool. Similar to POSIX AIO on Linux/glibc, except you can use something more sane than signals for signaling completion (e.g. pipes or a pure userspace queue). See also e.g. http://blog.libtorrent.org/2012/10/asynchronous-disk-io/ So, the only solution that has the potential to work well and is portable is #3. It's a fair amount of work, though, and in the end I wasn't convinced it was worth the effort.
