If you use HashConcurrentUser, the daemon flips into read-write
locking mode (internally) which should work safely. Typically this is
for global databases, but I am pretty sure the framework is there to
support multiple users.
Jonathan
On Jan 14, 2007, at 5:11 PM, Frank Cusack wrote:
<http://mailing-list.nuclearelephant.com/5003.html>
But more importantly (and more generally), the fcntl locking used by
the hash drivers is designed to assure per-process control over a
given file. For a multi-threaded daemon, the locking is going to have
*no* internal effect ...
That sucks, since as you noted later in the thread, the docs say the
hash driver is thread safe. I guess this is what is causing my
hash corruption. I wish I had found this thread BEFORE I ran into
problems.
The attached patch implements a thread-safe per-user lock for the hash
driver. After minimal testing, it seems to be ok.
It has a failure case that if the pid is not written correctly into
the
lock file (fs corruption or disk full or whatever) and dspam
crashes and
leaves the lock behind, future instances of dspam will not reclaim the
lock. Maybe something as simple as checking the return value of
fclose()
would help. I didn't bother as it seems that under the same
conditions
the hash driver itself isn't robust enough against hash corruption to
worry about lock files.
It has another rarer failure case that if a lock is written correctly
but dspam crashes and leaves the lock behind, and when or by the time
a new dspam tries another delivery for that user, there is another
process
running with the pid of the previous dspam (the pid written into
the lock
file), dspam will not reclaim the lock as long as that other
process is
running. This should be exceedingly rare. A good fix might be for
dspam
to iterate over and remove all possible locks when starting up.
Assuming
dspam protects itself against multiple invocations, at startup it is
guaranteed that any existing locks are invalid.
There should also probably be a way to choose between the previous
fcntl
locks and the new dot-lock style lock (file existence lock). So that
folks that run invoke a dspam per delivery, where fcntl is sufficient,
are not subject to the type of failures that the patch introduces.
-frank
<dspam-3.6.8-hash-lock.patch>
