> 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

Reply via email to