This is the mail archive of the cygwin-patches 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]

Re: [PATCH] Initialize IO_STATUS_BLOCK for pread, pwrite


On Nov 30 01:50, Mark Geisert wrote:
> On Wed, 29 Nov 2017, Corinna Vinschen wrote:
> > On Nov 29 13:36, Corinna Vinschen wrote:
> > > On Nov 29 13:04, Corinna Vinschen wrote:
> > > > - If you do async IO, you have to handle STATUS_PENDING gracefully:
> > > > 
> > > >   - The IO_STATUS_BLOCK given to NtWriteFile *must* exist for the
> > > >     entire time the operation takes after NtWriteFile returned
> > > >     STATUS_PENDING.  An IO_STATUS_BLOCK fhandler member comes to mind,
> > > >     maybe fhandler_base_overlapped::io_status can be reused.
> > > 
> > > No, wait.  There can be more than one outstanding aio operations on the
> > > same descriptor.  Therefore the IO_STATUS_BLOCK must be connected to the
> > > aiocb struct one way or the other, becasue only that struct is local to
> > > the aio operation.
> > 
> > I guess that's what the Linux man page aio(7) subsumes under
> > 
> >  struct aiocb {
> >    [...]
> > 
> >    /* Various implementation-internal fields not shown */
> >  };
> 
> 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.

> ..mark
> 
> P.S. I'll look into IRC clients.  You've suggested it before and I just
> recall the wild IRC days in the 90s with egg drops and bots and bans and it
> seemed like a time sink I couldn't afford.  Maybe #cygwin-developers
> on freenode is more civilized :-)).

Freenode is pretty civilized anyway.  As IRC client I suggest weechat.


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]