This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Dec 12 01:11, Mark Geisert wrote:
> 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.

If you use threads, you will have to change your code to use cygthreads
instead of pthreads.  Pthreads are a userspace concept, cygthreads are
used for internal tasks.

However, using async IO, the only change necessary would be to change
prw_open to open an async handle, and pread/pwrite to wait for the
result if the current I/O is NOT async.  It may be necessary to add a
parameter or two to the pread/pwrite fhandler methods, but all the rest
of the functionality could be in the callers.

Please stop thinking in Win32 overlapped I/O.  I have no idea why
Microsoft uses this term.  Under the ntdll hood, a handle is either
synchronous (Keeping track of file position, waiting for read/write to
complete) or asynchronous (Not keeping track of file position, returning
STATUS_PENDING rather than waiting for completion, based on using the
FILE_SYNCHRONOUS_IO_{NON}ALERT.

On async handles, you can wait for an event object to be signalled, or
you can ask the NtReadFile/NtWriteFile functions to call a completion
routine.

> There is an O_ASYNC flag in some non-POSIX Unixes but what little
> documentation

No, if we had to create a new open flag for this functionality it would
be wrong.

> 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.

Yes, but with an arbitrary signal.  Alternatively aio can start a
pthread on completion, basically all the stuff sigevent is supposed to
handle.

> I'm also unsure one can add overlapped capability to an existing Win32
> handle.

That's what prw_open is for.

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

Not sure.  You will have to change the threading stuff anyway and what's
working in user space is pretty different from how you do it in Cygwin.
Also, wouldn't it be nice to use the methods already provided by the OS
for just such an opportunity?  Changing the pread/pwrite/prw_open
methods to support aio_read/aio_write should be pretty straightforward.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]