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.
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. > 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... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
signature.asc
Description: PGP signature
