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