On Mon, 2011-04-04 at 14:08 -0700, Hongli Lai wrote: > On 4 apr, 17:01, John Leach <[email protected]> wrote: > > On Mon, 2011-04-04 at 05:35 -0700, Hongli Lai wrote: > > > On Apr 4, 2:21 pm, John Leach <[email protected]> wrote: > > > > You don't need to buffer your own writes to protect against > > > > inter-message interleaving. Opening the log file in O_APPEND mode > > > > should get you that (assuming each message is made with one write call) > > > > > That only works if the data you're writing is smaller than PIPBUF, > > > which seems to be 512 bytes on most systems. And don't forget Windows, > > > I don't what kind of guarantees it gives to file append operations. > > > > A POSIX write call to a file in O_APPEND writes to the end of the file > > atomically - writes should never get interleaved. Linux does this. I > > can't find any mention of this not working in Windows (it does support > > O_APPEND apparently), but I haven't tested it. It isn't guaranteed over > > NFS though. > > > > I'm speaking slightly more from theory than practice, but I can't > > reproduce an interleaving write on Linux. > > > > I'm pretty sure PIPE_BUF doesn't apply to files. > > > > John. > > Is there anything in the standards that say appending to files is > always atomic? I can't find anything that indicate that it isn't just > undocumented linux behavior. >
http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html "If the O_APPEND flag of the file status flags is set, the file offset shall be set to the end of the file prior to each write and no intervening file modification operation shall occur between changing the file offset and the write operation." and then: "If the value of nbyte is greater than {SSIZE_MAX}, the result is implementation-defined." SSIZE_MAX is apparently guaranteed to be a minimum of 32k-1 John. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
