apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r512557 - in /apr/apr-util/trunk: CHANGES dbm/sdbm/sdbm.c
Date Wed, 28 Feb 2007 08:52:59 GMT
Justin Erenkrantz wrote:
> On 2/27/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> 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.

Mime
View raw message