[PATCH] Initialize IO_STATUS_BLOCK for pread, pwrite

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Dec 1 09:30:00 GMT 2017

On Dec  1 00:44, Mark Geisert wrote:
> 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.

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.

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

NtQueryInformationFile with info class FileModeInformation.

However, I was thinking about using threads for aio.  Do we really need
them?  Should't it be fairly easy to implement aio with the stuff we
already have, just by using an asynchronous handle?  We could utilize
fhandler_disk_file::prw_open to open a handle always asynchronous and
the pread/pwrite functions to get an extra parameter to indicate if
it should wait for completion (ordinary pread/pwrite) or if it should
just return (called for aio operation).

> Thanks again,

No worries.  I' m pretty excited that you work on this aio stuff.
This is one of the block of functions I'm kicking down the road
for much too long...


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20171201/c6f2638f/attachment.sig>

More information about the Cygwin-patches mailing list