Ideas wanted for TXN and Concurrent store recovery handling

[Tom Anderson]

From: "Matthias Andree" <matthias.andree at gmx.de>
> The daemon wouldn't need to spawn children IMO, it can be
> single-threaded to reduce locking contention in the data base, and
> might, after all, eliminate the need for any kills to resolve a deadlock.

I'd think it'd be efficient to run concurrent child processes in a
moderately large mail server receiving several emails per second.  Anything
over like 10 users I'd imagine.  If emails arrive faster than bogofilter can
process them sequentially, then they'd just pile up.

> Any running bogofilter process would claim a shared lock and then try to
> upgrade to an exclusive lock once. Only one process can hold the
> exclusive lock, and that process would then be in charge of running
> recovery.

I thought your initial problem was when this process having the exclusive
lock hung for some reason.

How do other programs such as system loggers to it?  They fork multiple
children, don't they?

Maybe they haven't solved it either?
http://sources.redhat.com/ml/libc-alpha/2003-09/msg00059.html

> The remaining question is how does the process know if regular
> or catastrophic recovery is needed?  Neither does harm, but the latter
> can take a whole age or two...

What condition differentiates two and necessitates the latter?

Tom


> -- 
> Matthias Andree
>
> Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)
> _______________________________________________
> Bogofilter-dev mailing list
> Bogofilter-dev at bogofilter.org
> http://www.bogofilter.org/mailman/listinfo/bogofilter-dev
>