apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: exclusive file access under Windows (Was Re: svn commit: r1534139 - in /apr/apr/branches/1.5.x: ./ CHANGES file_io/win32/readwrite.c)
Date Wed, 23 Oct 2013 01:34:02 GMT
On Tue, 22 Oct 2013 08:13:08 -0400
Jeff Trawick <trawick@gmail.com> wrote:

> On Tue, Oct 22, 2013 at 6:04 AM, Stefan Ruppert <sr@myarm.com> wrote:
> 
> > Am 21.10.2013 20:39, schrieb Jeff Trawick:
> >
> >> On Mon, Oct 21, 2013 at 12:41 PM, Stefan Ruppert <sr@myarm.com
> >> <mailto:sr@myarm.com>> wrote:
> >>
> >>     Am 21.10.2013 16:22, schrieb Jeff Trawick:
> >>
> >>         On Mon, Oct 21, 2013 at 8:57 AM, <trawick@apache.org
> >>         <mailto:trawick@apache.org>
> >>         <mailto:trawick@apache.org <mailto:trawick@apache.org>>>
> >> wrote:
> >>
> >>              Author: trawick
> >>              Date: Mon Oct 21 12:57:05 2013
> >>              New Revision: 1534139
> >>
> >>              URL: http://svn.apache.org/r1534139
> >>              Log:
> >>              Merge r960671 from trunk:
> >>
> >>              Only deal with the mutex when XTHREAD is enabled. This
> >>         increases the
> >>              performance of buffered reads/writes tremendously.
> >>
> >>              * file_io/win32/readwrite.c:
> >>                 (apr_file_read, apr_file_write): only manipulate
> >> mutex when XTHREAD
> >>
> >>              Submitted by: Ivan Zhakov <ivan visualsvn.com
> >>         <http://visualsvn.com> <http://visualsvn.com>>
> >>
> >>
> >>
> >>         Trunk continues to allocate a mutex if buffered, even if
> >> the XTHREAD
> >>         flag is on (a minor detail I suppose).  That presumably is
> >> a simple fix
> >>         after double checking all the references to mutex or
> >> buffered in the
> >>         code used on Windows.  ISTR other concerns about the mutex
> >> or XTHREAD,
> >>         but I think this is an orthogonal issue.
> >>
> >>
> >>     Regarding exclusive access to a file under windows I filed a
> >> bug in 2010:
> >> https://issues.apache.org/__**bugzilla/show_bug.cgi?id=50058<https://issues.apache.org/__bugzilla/show_bug.cgi?id=50058>
> >> <https://issues.apache.org/**bugzilla/show_bug.cgi?id=50058<https://issues.apache.org/bugzilla/show_bug.cgi?id=50058>
> >> **>
> >>
> >>     Using the apr_file_lock()/apr_file___**unlock() under Windows
> >> in
> >>
> >>     append mode will deadlock the current thread! In the time of
> >> 2010 I just removed the apr_file_lock()/apr_file___**unlock() code
> >> within the
> >>
> >>     readwrite.c module. But a better solution is to support nesting
> >>     within apr_file_lock()/apr_file___**unlock() API calls!
> >>
> >>
> >>     Any comments?
> >>
> >>     Stefan
> >>
> >>
> >> I thought it was this simple for append:
> >>
> >> On Unix a lock isn't needed because the APR implementation there
> >> uses O_APPEND, which is atomic (subject to the size of the write I
> >> suppose)*; on Windows there's no such feature and APR has to use a
> >> lock to make it equivalent.  So the app shouldn't be getting a
> >> lock.
> >>
> >> Is that consistent with what you see?
> >>
> >
> > The problem arise when you want to use the
> > apr_file_lock()/apr_file_**unlock() calls to protected multiple
> > calls to apr_file_write():
> >
> > 1) apr_file_open(FOPEN_APPEND);
> > 2) apr_file_lock();
> > 3) apr_file_write();
> > 4) apr_file_write();
> > 5) apr_file_write();
> > 6) apr_file_unlock();
> > 7) apr_file_close();
> >
> > Under Unix all works perfect. But under Windows the step 3) call to
> > apr_file_write() will deadlock, because the LockFileEx() should not
> > be called recursively...
> >
> > However, in the APR API docs there is nothing said about an atomic
> > write within apr_file_write(), thus from my point of view its up to
> > the application to make it atomic with the
> > apr_file_lock()/apr_file_**unlock() calls. On Unix its a nice side
> > effect that each call to apr_file_write() is atomic....
> >
> 
> An alternate interpretation ;)  Access to the O_APPEND semantics is a
> critical feature, and the lock on Windows was the best known way to
> map that feature.
> 
> 
> > The easist way to make it conistent is to support a nesting counter
> > within apr_file_lock()/apr_file_**unlock() which will also reflect
> > the APR API docs for that calls which are documented to be used
> > recursively!
> >
> 
> I generally agree, though I think the behavior of apr_file_lock() on
> Unix needs examination too so we understand more widely what is
> broken w.r.t. the documentation.  I guess testflock.c would be
> modified to verify that part of the documentation and then tested on
> a couple of Unix variations using the alternate low-level
> implementations.

I believe the multiple-choice answer (particularly, but perhaps not
exclusively on win32) is...

* support nested apr_file_lock(s)
* reorder win32 apr_file_writev to lock around multiple-segment writes

There is an implicit contract in apr_file_write and writev that the
operation is atomic, in as much as posix write[v] is supposedly atomic,
at least under most unix.


Mime
View raw message