Re: Caches, caches...

jredford@lehman.com
Fri, 18 Mar 94 09:35:49 -0500

>> 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.

rename(2) has an advantage that it can (maybe dosent) gaurentee that if
the implicit unlink(2) happens, then the renameing happens.

rename(2) will only fail when you have a permmissions problem or the
like. This will generally happen because the current .pyc is
unremovable and out of date, therefore you should simply remove
module.pid and go on, ignoring the old .pyc. Assuming that it is
likely the same as the file you just made presumes that the general
case involves two people rushing to make identical copies, which it is
not.

I dont follow the reference to a loop at all. It simply isnt likely
that you are going to have two competing processes writing this file,
much less three or more. And 'so what' if they are. the last one will
'win', and none will be the worse off for it.

--
John Redford (AKA GArrow) | 3,600 hours of tape.
jredford@lehman.com       | 5 cans of Scotchguard.