for review: bug fix for concurrent writes to `.d' files
Tyson Dowd
trd at stimpy.cs.mu.oz.au
Sat Feb 28 12:47:19 AEDT 1998
On 28-Feb-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 27-Feb-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > The fix is to write the dependency file to `<foo>.d.tmp' and
> > then rename the `.d.tmp' to `.d'. This ensures that the update
> > to the `.d' file is atomic.
>
> Well, gee, now we have a concurrent write problem for
> the `.d.tmp' files. Doh!
>
> Obviously we need to use io__tepnam. Let me try that again.
>
> [Testing this revised change revealed bugs in io__tmpnam;
> I'll commit the fixes for those as a separate change.]
>
> --------------------
>
> Estimated hours taken: 1
>
> compiler/modules.m:
> Fix a bug with parallel makes where the `.d' files were being
> stuffed up because two different invocations of the Mercury
> compiler were writing to them at the same time.
> The problem occurs because the `.d' file is written out
> both when creating the `.c' file and when creating the
> `.trans_opt' file, and these steps might happen in parallel.
>
> The fix is to write the dependency file to a unique temporary
> file name and then rename it to the desired `.d' file name when
> we're done. This ensures that the update to the `.d' file is atomic.
> [In theory this is not a 100% portable solution, because
> rename() might not be atomic, but in practice it should be
> fine, because rename() is atomic on all the platforms of
> interest (i.e. all the ones that support parallel GNU make).]
>
> An alternative fix would be to not write out the `.d' files
> when creating `.trans_opt' files. This would also be more
> efficient. However, the danger is that the `.d' files might
> not be updated often enough. I'm not really sure exactly
> how often they need to be updated, but the fix using
> renaming seems safer.
>
This change seems fine (now).
More information about the developers
mailing list