On Tue, Apr 27, 2010 at 5:47 AM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: Jeff Trawick [mailto:traw...@gmail.com] >> Sent: maandag 26 april 2010 23:14 >> To: APR Developer List >> Cc: Bert Huijben >> Subject: Re: Why does apr_file_read() with !APR_XTHREAD use mutexes on >> Windows >> >> 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.