FWIW, this won't protect you from the case where two processes
open the file at about the same time. The unlinked file
won't be openable by other processes, since the namespace
entry will be gone, but the two processes which already
have it opened can continue to access it.
The first process will do it's thing and then delete the
file. The second process will grab the lock on the still
opened file, and then process as if it had the lock --
it won't know the file has been unlinked. If you can
live with this, that's fine. If you want "exactly once"
semantics, it's not.
FWIW, in general it's not a good idea to try to use
an object's lock to synchronize the destruction of
that object -- it is easy to overlook a race condition.
You might get away with this in
certain cases, but in general you'll rest easier if
you use a different way. See one of the other
methods described above (e.g. Ovid's 'sentinel',
file renaming, etc.) | [reply] |
| [reply] |
Except I have only one process, set to append, in a directory it has permission to create files in, so that should be OK, yes?
| [reply] |
You are not protected against the race condition I
mentioned earlier. An unlink in Unix does not release the
data from the file
until the last file descriptor is closed. The second
process will be able to read whatever information
is in there (and write to it if it desires). Of course
other processes wont know this since the file's name
space entry is gone. The second process will
continue under the assumption that it was accessing the
locked file in a valid state (hey it was there when I
opened it!).In some cases, perhaps the
current one, this is ok
in others it is not -- it depends on the assumptions
being made after this section of code. In general if
you are going to do this, it is a good idea to put
a comment in your code that says you know about the
possible race condition and it is ok.
| [reply] |