apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject RE: cvs commit: apr/file_io/win32 filedup.c open.c readwrite.c
Date Tue, 29 Oct 2002 17:58:53 GMT

>> >The reason for locking the file is to mutex the file pointer. A file 
> opened for
> >overlapped i/o does not have a file pointer.
> >I'm not aware of any restrictions but I've not tested this patch and 
> I think the
> >results will be less than predictable. For instance, we lock the file, call
> >WriteFile and get back IO_PENDING, then we unlock the file. Maybe the i/o
> >occured by the time we released the lock. Or maybe not.  The 
> function is broken,
> >with or without this patch when used for writing to files opened for 
> overlapped
> >i/o. I'm not sure the best way to fix it (or even if we should fix 
> it). I'm -0
> >on this patch.
> 
> Bill, now you aren't reading :-)
> Please take a moment and review apr_file_seek()...
> 
> The code never sets the file pointer through the win32 API.  There is
> no bug.  As long as we hold the file lock, the size won't change.  The
> WriteFile uses the filePtr value for the overlapped value.
> 
> apr_file_seek, for XTHREAD/overlapped files, simply updates filePtr based
> on your request, relative to the old filePtr value :-)  So we still want the
> file lock, to hold the length of the file constant, until our file 
> write completes.
> 
> Hope that clears things up.
> 
> Bill

Ahh, there's much magic in apr_file_seek.  Okay, +1 on the patch. It will work.

Bill 

Mime
View raw message