[PATCH] Initialize IO_STATUS_BLOCK for pread, pwrite

Mark Geisert mark@maxrnd.com
Fri Dec 1 08:44:00 GMT 2017


On Thu, 30 Nov 2017, Corinna Vinschen wrote:
> 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.

I'd better take this info back to "the lab" and do some more digging. 
Thanks very much for these details and your earlier replies.  When I saw 
FILE_SYNCHRONOUS_IO_NONALERT in your reply, I remembered that I'm not 
using a Cygwin-supplied handle but rather a handle returned by Win32 
CreateFile().  Not only that, but using cygwin_attach_handle_to_fd() to 
get an fd to work with.  And then pwrite() creates its own handle (or 
reuses one (!)) to avoid messing up the seek pointer of the fd passed in.

I'm not specifying FILE_FLAG_OVERLAPPED, which is the only control one has 
over async- or sync-ness in Win32.  But maybe it's getting added somewhere 
on the way through these layers.  Is there a way to query handle 
attributes in order to find out if a handle is sync or async?  I'll dig.
Thanks again,

..mark



More information about the Cygwin-patches mailing list