> >> From: Sjoerd Mullender <Sjoerd.Mullender@cwi.nl>
> >> Subject: Re: Caches, caches...
> >> A better approach would be to write to a temporary file first and
> >> linking the temporary file to the .pyc file at the end. When linking
> >> fails, someone else was there before you, so you can ignore the error.
>
> And and even better approach would be to open module.pid, write out
> the file, close it, then rename(2) module.pid to module.'pyc', on
> POSIXy systems and something similar elsewhere.
This is sort of what I meant. I know Guido understood my meaning
since he made a remark about it.
> I dont know what you meant by linking, but there is always the case
> where someone was 'there before you' and wrote the old version of a
> pyc, and you need to write a new version, since the .py changed. There
> is no point in not over-writing what was already there, assuming it
> can be done atomically.
With linking, I meant using the link system call. This is just as
good as using rename, except that you have to unlnk the original
yourself, both when the link succeeds and when it fails.
Of course the temporary file must have a unique name, otherwise you'd
have the same problem as with the .pyc file. Basing the name on the
pid is fine.
It is a matter of debate what you should do when linking (or renaming)
fails. Ignoring the error (i.e. letting the other person's file
alone) is probably good enough. If the other process had finished
slightly sooner you'd have used its .pyc file anyway. Of course you
can also remove the new .pyc file and put your own in its place. This
you'd have to do in a loop because there may be even more processes
that are trying to write the .pyc file.
Sjoerd Mullender, CWI, P.O. Box 94079, 1090 GB Amsterdam, The Netherlands
E-Mail: Sjoerd.Mullender@cwi.nl; Phone: +31 20 592 4127; Fax: +31 20 592 4199
URL: <http://www.cwi.nl/cwi/people/Sjoerd.Mullender.html>