On Fri 11 Sep 1998, Philip Hazel wrote:
> On Fri, 11 Sep 1998, Paul Slootman wrote:
>
> > An alternative would be an #include type of mechanism for the config
> > file. I just had a quick look, but couldn't find anything like that.
> > The config file could then include a (one-liner) file that either says
> > "queue_whatever" or not, depending on the connection state.
>
> ... but then you have a race condition on the included file, don't you?
Well, I think it's less serious that the single-line included file might
not be read in the time window where it's being replaced, as (as far as
I'm concerned here) it's either empty or not, and if it's being
manipulated at the precise time exim reads the file, it's empty... which
is was a millsecond earlier or later, depending on the direction of the
state change.
> Actually, it is my understanding of Unix that you don't have a race
> condition, because the file is replaced by renaming (using mv rather
> than cp). Exim will read either the old file or the new file.
Actually, you're right! I'm still thinking of older unix systems, where
there wasn't an atomic rename() system call (you had to do it with
unlink(); link()). But then, there wasn't a mkdir() call either, you had
to do mknod() and then link . and .. yourself. Gave interesting results
if you screwed up that last part :-)
Anyway, on Linux it's documented explicitly for rename():
If newpath already exists it will be atomically overwrit
ten (subject to a few conditions - see ERRORS below), so
that there is no point at which another process attempting
to access newpath will find it missing.
So I now have less reservations about mucking about with the config file
"on the fly".
Thanks,
Paul Slootman
--
home: paul@??? | work: paul@??? | debian: paul@???
http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands
--
*** Exim information can be found at
http://www.exim.org/ ***
