> On Tue, Oct 29, 2002 at 12:15:19PM -0000, [EMAIL PROTECTED] wrote: > > stoddard 2002/10/29 04:15:19 > > > > Modified: file_io/win32 readwrite.c > > Log: > > Comment a not so obvious tidbit. > > > > Revision Changes Path > > 1.72 +5 -0 apr/file_io/win32/readwrite.c > > > > Index: readwrite.c > > =================================================================== > > RCS file: /home/cvs/apr/file_io/win32/readwrite.c,v > > retrieving revision 1.71 > > retrieving revision 1.72 > > diff -u -r1.71 -r1.72 > > --- readwrite.c 29 Oct 2002 02:19:50 -0000 1.71 > > +++ readwrite.c 29 Oct 2002 12:15:19 -0000 1.72 > > @@ -307,6 +307,11 @@ > > apr_off_t offset = 0; > > apr_status_t rc; > > if (thefile->append) { > > + /* apr_file_lock will mutex the file across processes. > > + * The call to apr_thread_mutex_lock is added to avoid > > + * a race condition between LockFile and WriteFile > > + * that occasionally leads to deadlocked threads. > > + */ > > apr_thread_mutex_lock(thefile->mutex); > > if (!thefile->pOverlapped) { > > rc = apr_file_lock(thefile, APR_FLOCK_EXCLUSIVE); > > Since this is already win32 specific code, why don't we just use win32 > primitives here? It seems it would probably be more efficient. > > -aaron
I don't disagree. There is some use in using the APR primitives just to exercise the heck out of them. Bill