Ideas wanted for TXN and Concurrent store recovery handling

[Tom Anderson]

On Wed, 2004-07-28 at 06:15, Matthias Andree wrote:
> Well, switching to a daemon might enable us to ease use in the network
> (as long as the load level remains acceptable), but will still be
> subject to the same problem, if the daemon goes down, it will be facing
> the same problems as the standalone bogofilter process today - how and
> when to recover, guard against concurrent recovery or recovery
> underneath use, and all that.

The daemon won't start if there is another instance already running, and
it won't start any children if it is doing recovery, which solves the
concurrent use/recovery problem.  You could have a lock flag in the
wordlist which is set when the daemon starts and is unset when it
cleanly exits.  Thus, if the daemon starts and this flag is set, then it
should do recovery.

> That's not my primary concern now, but how to avoid a bogofilter process
> (that might also be the daemon process) from waiting for an event that
> can never occur.

Such as what?  Query children via IPC to check their status; if there's
no response, kill it.

I never claimed to have all the answers, just an idea, as requested.  

Tom