Implementing aio_* and lio_* (async i/o) on Cygwin

Mark Geisert mark@maxrnd.com
Tue Dec 12 09:11:00 GMT 2017


I've got a proof-of-concept implementation working but haven't integrated 
it into my local Cygwin source tree yet.  This implementation uses a pool 
of pthreads to issue reads and writes asynchronously.  Using threads 
allows to operate transparently with the usual Cygwin-supplied file 
descriptors/handles that are set up for synchronous-only operation.

If I were to use Win32 overlapped i/o, as Corinna suggested as a 
possibility, there would have to be some supporting changes to Cygwin 
internals, I think.  Either file descriptors would have to always permit 
overlapped usage, or open() and/or fcntl() would have to allow some new 
flag to specify overlapped capability when creating a new fd/handle.

There is an O_ASYNC flag in some non-POSIX Unixes but what little 
documentation I can find online makes it sound like an inexact match to 
the need here.  It's used to signal (via SIGIO arrival) that space is 
available for a write, or that data is available for a read.  What it 
would need to do for aio_* semantics is to signal that a write or a read 
has completed.  For disk files one *might* consider these two viewpoints 
equal but I'd like to hear if anybody thinks differently.

I'm also unsure one can add overlapped capability to an existing Win32 
handle.  If you can, then we could have fcntl() add or remove it from a fd 
on the fly.  If you can't add it to an existing handle, then an open() 
would have to ask for the capability when creating an fd/handle.

Wouldn't it be easier (less modification of existing code) to just use the 
thread model?

Any thoughts on any part of this would be appreciated.
Thanks,

..mark

P.S. Google search aio_read(), aio_write() man pages for background.
P.P.S. I could put my PoC code up on my GitHub space for inspection.



More information about the Cygwin-developers mailing list