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] |
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?
..markP.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] |