Justin Erenkrantz wrote: > On 2/27/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: >> Any thread safety implications here? If the data isn't refreshed >> between writes, it seems this could be a major hassle. > > I don't think this opens us up to any more issues than we already have > with the current code. The APR file buffers are thread-safe in and of > themselves - essentially this doesn't alter anything except that we're > allowing APR to cache - the same as the FS or OS might do on its own. > You could not do buffering if the DBM was open for writing, but > really, I don't think that'd change anything of substance here as the > code isn't calling flush() or similar after each modification - so > there's never been a guarantee that changes would be committed on disk > at the instant the DBM was changed in memory. -- justin
There's a signficant difference between not calling flush 'anytime soon' and lazy writes, however :) If this was a flag to apr_sdbm_open, or was modified to interact with the existing locking logic, I'd have much more faith that this is a reasonable approach.
