apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Erenkrantz" <jus...@erenkrantz.com>
Subject Re: svn commit: r512557 - in /apr/apr-util/trunk: CHANGES dbm/sdbm/sdbm.c
Date Wed, 28 Feb 2007 09:12:05 GMT
On 2/28/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> There's a signficant difference between not calling flush 'anytime soon'
> and lazy writes, however :)

No - not really.

> 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.

I would appreciate it if you present a specific case where this breaks
something rather than vague generalities about how it might break
something.  As I said earlier, I view this as a very low-risk change
as SDBM uses APR's file locking semantics and doesn't support
concurrent reader/writer combinations.  If you want that facility via
BDB, you need newer versions of BDB (and even that tends to barf all
over itself on load).

If we do determine there is a case where it would break when SHARELOCK
is present (which I'm doubtful works given it doesn't even try to
flush), then we can either not set the buffering when APR_SHARELOCK is
set, or move the flag into apr_dbm's usage of SDBM - which, I hope we
agree, certainly doesn't permit multiple reader/writers with SDBM at
all.  -- justin

Mime
View raw message