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: Why does apr_file_read() with !APR_XTHREAD use mutexes on Windows
Date Mon, 26 Aug 2013 14:43:04 GMT
On Sat, 24 Aug 2013 00:33:38 +0400
Ivan Zhakov <ivan@visualsvn.com> wrote:
> >
> > Append is special, in that POSIX has an append flag on open() which
> > handles atomicity of seek-to-end+write; so that mutex isn't needed
> > on all operating systems.  This is a case where Windows needs a
> > mutex but Unix doesn't.
> Actually Windows supports atomic seek-to-end+write: file should be
> opened with FILE_APPEND_DATA access right only [1] or Offset and
> OffsetHigh should be 0xFFFFFFFF if overlapped I/O is used [2].
> I'm reopening this thread because in Subversion we found case where we
> need true atomic append across processes/threads. So I'm willing to
> create a patch implementing atomic append on Windows. Is right idea
> for APR or not? Any concerns will be very helpful.
> [1]
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa363778%28v=vs.85%29.aspx
> [2]
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa365747%28v=vs.85%29.aspx

This is even worse than I thought...

1. we aren't protecting segments of writev within the apr_file_writev
   call with the mutex (as Ivan notes)

2. the mutex is used for buffered output (which makes sense, if
   you have multiple threads with the same apr_file_t context which
   write to the same buffer...)

3. The mutex -> file lock looks backwards and we release the mutex...
   it is a complete mess.

4. If the file lock doesn't support nested locks (have yet to check)
   then this whole code path is foobar for anyone using the file lock
   API within their own code (as would be appropriate for complex
   write operations).

5. On failure we use pOverlapped with a thread-shared overlapped IO
   structure and hEvent signal.  This is not unique per-thread and is
   clearly a design error if we pass this without holding the mutex.

I need to go a decade back in svn to pick up the initial principals
and we need to recode both write and writev appropriately.

If opened for append, unbuffered, non-xthread then I can see us finding
our way to the atomic write-for-append method on unix and windows.  But
that method will force us to create the overlapped and hEvent on each
call to write to ensure they are unique per-thread, slowing things down
considerably, in the write failure case.

View raw message