[resurrecting this very old thread, see my reply below] On Tue, Apr 27, 2010 at 3:03 PM, Jeff Trawick <traw...@gmail.com> wrote: > On Tue, Apr 27, 2010 at 5:47 AM, Bert Huijben <b...@qqmail.nl> wrote: [...]
>>> On Mon, Apr 26, 2010 at 4:38 PM, William A. Rowe Jr. >>> <wr...@rowe-clan.net> wrote: >>> > On 4/26/2010 2:19 PM, Jeff Trawick wrote: >>> >> >>> >> So I don't think there's any hidden "reason" why a mutex should always >>> >> be obtained on Windows. I too wouldn't be surprised if the fix breaks >>> >> some app code somewhere. >>> > >>> > Keep in mind fd-based operations are atomic on Unix, but not so on >>> windows. >>> >>> Since these are buffered files, it doesn't even come down to >>> differences in OS file operations; operations on the buffer would be >>> the expected failure point. >>> >>> So the question is whether or not APR expects multi-threaded apps >>> sharing a buffered file to turn on the XTHREAD flag. >> >> Another thing I was thinking about is how the append mode is used. I can >> imagine that is used to write to a single logfile in a multithreaded >> application. (But if we don't enable the mutex on other operating systems, >> it should probably be fixed in the application) > > 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 -- Ivan Zhakov
