Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:
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
That sounds like the domain of of filelocking (fp)Flock.
Agreed. I've already subclassed TIniFile so I can do things like parsing
array- and record-like settings, is there any way of hooking the file
open/close to insert locks?
The more risky case is if there are e.g. multiple daemons or apps trying
to save state when a UPS signals imminent shutdown.
Have all systems regularly write local files in something that is not
cleared on startup. (e.g. change clearing /tmp to a monthly cronjob
instead of startup)
On startup check for crash (local file exists) and if the
local file is newer than the server, copy and continue starting up.
Provided that it's just unimportant stuff- e.g. the visual appearance of
a program controlling a daemon- it's probably not worth updating.
--
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
