On Mon, Oct 21, 2013 at 12:41 PM, Stefan Ruppert <[email protected]> wrote:
> Am 21.10.2013 16:22, schrieb Jeff Trawick: > >> On Mon, Oct 21, 2013 at 8:57 AM, <[email protected] >> <mailto:[email protected]>> 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>> >> >> >> 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> > > 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? *IIUC this isn't true for NFS -- Born in Roswell... married an alien... http://emptyhammock.com/
