Reinier Olislagers wrote:
On 16-2-2013 9:09, Sven Barth wrote:
On 15.02.2013 23:54, Mark Morgan Lloyd wrote:
If multiple, related, programs running on unix (Linux, Solaris etc.)
refer to the same configuration file accessed via a TIniFile, is there
any recommended "good practice" to ensure that they don't try to update
it simultaneously?
In the case that I'm thinking of, I don't anticipate e.g. multiple
logins trying to write setup information at the same time. The more
risky case is if there are e.g. multiple daemons or apps trying to save
state when a UPS signals imminent shutdown.
This might be for Windows, but I think this applies here as well:
http://blogs.msdn.com/b/oldnewthing/archive/2004/11/22/267890.aspx
Security problems with world-writable files? Yes, that problem applies
to *nix as well but Mark has given no indication his config files are
world-writable. (Even if the logins Mark speaks of run under different
user accounts, there's such a thing as groups on *nix, too :) )
[Checks link] I agree. The specific case I'm thinking of is where a
number of related daemons running (after any low-numbered sockets have
been grabbed) as the same user. Since they will be referring to the same
database servers and probably to common tables it makes sense to use a
common configuration file, this also makes it much easier since somebody
setting up a new collaborating system can be sent a template for the
single .ini required.
I think I'm leaning towards an arrangement where important stuff
(database names etc.) is written to the common .ini as soon as it is
entered into whichever program is dominant, but less-important stuff
(window sizes etc.) which might be updated at termination is kept in its
own file. There's still a risk that multiple instances of the same
program could interfere with each other, but the worst case result will
be messed up screen layout and it will always be fixable by deleting the
relevant .ini.
UPS shutdown: no experience with that - I'd expect the process to just
get a regular kill signal; perhaps the OS/UPS driver provides dbus (or
other messaging layer) notifications.
If the data is not that important, wouldn't a naive approach like a loop
that
- repeats say max 3x,
- tries to save the data,
- catching exceptions coming from TIniFile, then waiting a random small
amount of time
- giving up after those 3x
help?
Obviously, this problem would be alleviated if you run under multiple
different accounts (normal applications) and properly save settings
somewhere in the user's ~ directory rather than a systemwide path (which
the FPC getconfig... forgot exactly supports).
The notable thing about UPS shutdowns is that in at least some cases a
system first signals term then after five seconds signals kill. I think
that initial term is going to be problematic where shared data is
involved, since multiple programs can receive it simultaneously.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
