Path: csiph.com!usenet.pasdenom.info!gegeweb.org!usenet-fr.net!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Sun, 08 Jul 2012 22:57:56 +0200
From: Laszlo Nagy <gandalf@shopzeus.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: How to safely maintain a status file
References: <CAOV1wRVtm27yWez1HZuN8=ia-TyM2aXp9QCUbSZ5aZExP_ZChA@mail.gmail.com> <sanjv7lo0vb3rlhip4ov1gpgp4gs51bvfr@invalid.netcom.com>
In-Reply-To: <sanjv7lo0vb3rlhip4ov1gpgp4gs51bvfr@invalid.netcom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1926.1341781085.4697.python-list@python.org>
Lines: 55
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:25052

On Sun, 8 Jul 2012 21:29:41 +1000, Richard Baron Penman 
<richardbp@gmail.com> declaimed the following in gmane.comp.python.general:
>> and then on startup read from tmp_file if status_file does not exist.
>> But this seems awkward.
>>
> 	It also violates your requirement -- since the "crash" could take
> place with a partial "temp file".
>
> 	I'd suggest that, rather than deleting the old status file, you
> rename IT -- and only delete it IF you successfully rename the temp
> file.
Yes, this is much better. Almost perfect. Don't forget to consult your 
system documentation, and check if the rename operation is atomic or 
not. (Most probably it will only be atomic if the original and the 
renamed file are on the same physical partition and/or mount point).

But even if the rename operation is atomic, there is still a race 
condition. Your program can be terminated after the original status file 
has been deleted, and before the temp file was renamed. In this case, 
you will be missing the status file (although your program already did 
something just it could not write out the new status).

Here is an algorithm that can always write and read a status (but it 
might not be the latest one). You can keep the last two status files.

Writer:
*    create temp file, write new status info
* create lock file if needed
* flock it
* try:
*    delete older status file
*   rename temp file to new status file
* finally: unlock the lock file

Reader:

* flock the lock file
* try:
*    select the newer status file
*   read status info
* finally: unlock the lock file

It is guaranteed that you will always have a status to read, and in most 
cases this will be the last one (because the writer only locks for a 
short time). However, it is still questionable, because your writer may 
be waiting for the reader to unlock, so the new status info may not be 
written immediatelly.

It would really help if you could tell us what are you trying to do that 
needs status.

Best,

    Laszlo