> 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