On Thu, Nov 23, 2023 at 05:42:10PM +, Emmanuel Dreyfus wrote:
> On Thu, Nov 23, 2023 at 05:36:06PM +, Joe Orton wrote:
> > 3) in the mean time I worked up a PR for mod_dav_fs which adds a global
> > mutex around the dbm lockdb use. This passes my stress tests for the
> > first time.
>
>
On Thu, Nov 23, 2023 at 05:36:06PM +, Joe Orton wrote:
> 3) in the mean time I worked up a PR for mod_dav_fs which adds a global
> mutex around the dbm lockdb use. This passes my stress tests for the
> first time.
How concurent is the stress test?
In the past, I have been badly hurt by a
Adding dev@httpd to a dev@apr thread about apr_dbm locking being broken.
On Sun, Nov 12, 2023 at 07:43:13AM -0600, Greg Stein wrote:
> Or, apps can stick to an older APR. ... we don't have to carry this forward
> into future versions of APR (IMO).
>
> To your point, it is probably a single page
On Sat, Nov 11, 2023 at 4:21 AM Nick Kew wrote:
> > On 9 Nov 2023, at 16:15, Greg Stein wrote:
> >
> > Personally, I'd deprecate apr_dbm entirely, and direct all clients
> towards sqlite.
>
>...
> +1 to deprecting apr_dbm, provided we explain exactly why (so users
> are clear whether or not it
ter, *and* it handles
> processes/threads. I really don't see a reason for DBM nowadays.
>
> Who can justify using (say:) ldbm over sqlite?
Legacy apps? I first used ndbm more than 30 years ago. Software from
that era is still in use, and might crop up in someone's work today.
I *think*
Personally, I'd deprecate apr_dbm entirely, and direct all clients towards
sqlite.
The DBMs were intended for simple key/value stores 20 years ago. We have
much better tech now. Sqlite does K/V so much better, *and* it
handles processes/threads. I really don't see a reason for DBM nowadays.
Who
On Mon, Sep 25, 2023 at 03:58:18PM +0100, Joe Orton wrote:
> It is unspecified whether the apr_dbm.h interface is safe to use for
> multiple processes/threads having r/w access to a single database.
> Results appear to be:
>
> - sdbm, gdbm are safe
> - bdb, ndbm are not safe
I developed a
On 27.09.2023 14:37, Joe Orton wrote:
On Mon, Sep 25, 2023 at 05:37:00PM +0200, Branko Čibej wrote:
IIRC, Berkeley DB multi-process concurrency is managed through an on-disk
"register" file external to the actual key/value store. The key/value store
format is not affected by the presence of
On Mon, Sep 25, 2023 at 05:37:00PM +0200, Branko Čibej wrote:
> IIRC, Berkeley DB multi-process concurrency is managed through an on-disk
> "register" file external to the actual key/value store. The key/value store
> format is not affected by the presence of this file. The DB_REGISTER
> mechanism
On 25.09.2023 16:58, Joe Orton wrote:
It is unspecified whether the apr_dbm.h interface is safe to use for
multiple processes/threads having r/w access to a single database.
Results appear to be:
- sdbm, gdbm are safe
- bdb, ndbm are not safe
(Berkeley DB obviously can be used in a way which
It is unspecified whether the apr_dbm.h interface is safe to use for
multiple processes/threads having r/w access to a single database.
Results appear to be:
- sdbm, gdbm are safe
- bdb, ndbm are not safe
(Berkeley DB obviously can be used in a way which is safe for multiple
r/w users but it
11 matches
Mail list logo
