Ideas wanted for TXN and Concurrent store recovery handling

[Matthias Andree]

"Tom Anderson" <tanderso at oac-design.com> writes:

> From: "Matthias Andree" <matthias.andree at gmx.de>
>> > Perhaps you can ping the
>> > running process by raising a signal.  Don't know if any of that helps
>> > or if its just a mental fart.
>>
>> I'd wondered how I can do that without adding such a timeout for each
>> and every Berkeley DB call and with restarting the time for any progress
>> the process makes. Hm.
>
> Others have discussed in the past creating a bogofilter daemon.  You'd have
> more control over zombies if every process was a child of the daemon.

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.

> That would also allow you to store lock information in memory rather
> than writing to disk as each child could ask permission from the
> parent.

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.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)