On Nov 30 01:50, Mark Geisert wrote:
Yes, I believe that's correct. But in my aio implementation for Cygwin, I'm
not using overlapped I/O or any kind of async or nonblocking write. I'm
using separate threads to do plain vanilla blocking writes (via pwrite if
able). I'm doing this because I'm operating with user-supplied file
descriptors that might or might not be underlain with async-capable Windows
handles.
(It's my understanding that if one wants to do overlapped I/O on a Windows
handle, one has to request that explicitly when creating the handle. I
don't think Cygwin does this by default. Corrections welcome.)
Right, Cygwin opens files with FILE_SYNCHRONOUS_IO_NONALERT by default,
unless it's a handle for meta operations only.
But then I don't understand in what situation you see pwrite return a
STATUS_PENDING. This should only occur with async I/O.
So in this environment seeing pwrite() return with a short write count, even
though it's understandable that the underlying Windows write might still be
underway, is a real problem.
Something's really fishy here. A synchronous write should *never*
return with STATUS_PENDING. This breaks so many assumptions, Cygwin
wouldn't practically work at all.
A blocking pwrite() (i.e., not overlapped or async in any way) has to wait
for the underlying NtWriteFile() to complete in order to get a correct write
count and/or correct final status code, doesn't it?
Yes, in theory, but if you use the default handles opened by
fhandler_base::open, pwrite should wait as is because NtWriteFile
doesn't return prematurely.