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 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.)

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. Because, if I use the short count to determine that I need to write the remainder of a buffer, it'll have been written twice: once by the late-finishing pwrite and again by the
recovery code.

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?

..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 :-)).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]