Locking is the usual means of guaranteeing one-at-a-time access to
system resources like mailboxes --- most people on this list probably
understand well the problems that can arise from uncontrolled concurrent
write access. We talk about locking in Exim often enough, but I'd like
to address the wider issues a little and ask a few questions.
First of all, still within Exim's control, mailboxes are locked during
local delivery and dbm files are locked during lookup, fine. Is there
anything else that Exim locks? [Lsearch'd files are an obvious candidate
since they may change concurrently with Exim's lookups, just like dbms.]
Secondly, one can assume that Exim's locking is safe on a single machine
under access by multiple instances of Exim itself, as well as with NFS-
mounted filestores used by multiple instances of Exim executing on one
machine, and also when Exim instances execute on separate machines. True?
What about log files, spool files, and so on? Which items can safely
be shared between multiple parallel (not just concurrent) instances of
Exim executing on different hosts but sharing NFS space? (Presumably
not *every* filestore object is locked by Exim before use, but that's
OK as long as we know exactly which objects are and which aren't.)
Now comes the difficult bit, as we bring in other software.
Access to mailboxes is carried out under lock control by local user
mail agents and system POP3 daemons. How safe are we in the presence
of alternative locking systems or libraries? Is there an issue here
at all? Do we have to read the small print on mail readers and POP3
daemons to be certain that all is OK and compatible with Exim, or is
it just that I enjoy worrying about concurrency? :-)
Finally, when we interface our local facilities to linear or dbm files
used to control Exim, is there a preferred (read as "safest") method of
updating such files? If there is any doubt at all about compatibility
between Exim's locking and that native to the host on which it is running
then I think it would be useful to supply with the Exim package a locking
wrapper that would guarantee safe and lock-efficient updating of shared
resources within an Exim environment. Some might feel that the window of
opportunity for mutex faults doesn't warrant going to such lengths, but
in many production systems that try to focus on quality, availability and
lack of hiccups, such things can be important.
Rich.
--
########### Dr. Rich Artym ================ PGP public key available
# galacta # Email : rich@??? 158.152.156.137
# ->demon # Web : http://www.galacta.demon.co.uk - temp page only
# ->ampr # AMPR : rich@g7exm[.uk].ampr.org 44.131.164.1 BBS:GB7MSW
# ->NTS # Fun : Unix, X, TCP/IP, kernel, O-O, C++, SoftEng, Nano
########### More fun: Regional IP Coordinator Hertfordshire + N.London
--
* This is sent by the exim-users mailing list. To unsubscribe send a
mail with subject "unsubscribe" to exim-users-request@???
* Exim information can be found at http://www.exim.org/
