On 20 Oct 2002 11:30:35 -0400, Jeff Trawick wrote: >"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes: > >> At 07:08 AM 10/20/2002, Bill Stoddard wrote: >> >Why do we need to call SetFilePointer to each call of apr_file_write()? In >> >the common case where only threads in a single process write to a file, >> >calling SetFilePointer is a waste of cycles. If threads from multiple >> >processes are writing to a file, then we are broken unless the application >> >explicitly serializes access to apr_file_write() >> >> I'll take a wild guess... >> >> Unix append mode -always- writes to the end of the file, even when it is >> in use by multiple processes. Win32 has no absolute, atomic append >> mode for it's file open. >> >> But you are correct, there is a race here that even the 'emulation' falls >> down. > >Maybe APR_APPEND needs to be cheap/simple append a la stdio append: we >seek to the end of the file at open time and forget about it after >that. > >Then we need new APR_WRITE_AT_END or something better named which is >the expensive atomic append. For Unix, this enables O_APPEND on the >file and the kernel handles the details. For Win32, this enables >acquire-global-mutex + setfileptr + release-global-mutex prior to >every write. But then that has issues with non-related processes >sharing the mutex.
Or you can write-lock the file around the seek/write pair. That's what I ended up doing for OS/2 which has the same behaviour. The lock & seek could be avoided if the file was opened in "deny write" sharing mode but apr_file_open() doesn't have any way to specify that at the moment & it wouldn't help with logs shared between processes. -- ______________________________________________________________________________ | Brian Havard | "He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy!" - Life of Brian | ------------------------------------------------------------------------------
