[PATCH] Initialize IO_STATUS_BLOCK for pread, pwrite

[Mark Geisert]

On Fri, 1 Dec 2017, Corinna Vinschen wrote:
> On Dec  1 10:30, Corinna Vinschen wrote:
>> On Dec  1 00:44, Mark Geisert wrote:
>>> [...]
>>> 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.
>>
>> Ouch.
>>
>>> And then pwrite() creates its own handle (or reuses one (!)) to avoid
>>> messing up the seek pointer of the fd passed in.
>>
>> Wait.  Not "re-use", but "re-open".  If you're more familiar with POSIX
>> terms, this is along the lines of the fdopen(3) call, just on the NT
>> API level.  There's an equivalent Win32 function since Windows 2003
>> called ReOpenFile.
>>
>> In terms of pread/pwrite, the new handle shares the same settings with
>> the original handle.  However, if you use cygwin_attach_handle_to_fd,
>> there's a chance information got lost.  Nobody actually uses this call ;)
>>
>> In terms of FILE_SYNCHRONOUS_IO_NONALERT, this is stored in
>> fhandler_base::options, utilizing the get_options/set_options methods.
>> I have a hunch that cygwin_attach_handle_to_fd fails to call set_options,
>> thus options is 0 when you call pwrite, thus the new handle is opened
>> without FILE_SYNCHRONOUS_IO_NONALERT and all the other option flags
>> we use by default.
>
> It's more than a hunch.  Of course the info gets lost since
> none of the functions called by cygwin_attach_handle_to_fd calls
> NtQueryInformationFile(FileModeInformation) to fetch the options.

Bang.  There it is.  Let me fix the offending program to just use 
Cygwin-supplied handles and make sure this bug of mine is squashed.  I'll 
report back but it might be a few days.

I'm open to using overlapped I/O for the usual read & write cases of aio 
but there are some extensions I have in mind that don't allow for 
overlapped so I think I need to have threads handle them.  I might combine 
the two.  Using overlapped for the common case would, I think, allow me to 
reduce the number of worker threads hanging around.  Thanks for the input!

..mark