Pekr:
> the only technique I can come up with right now is to
> use some kind of time-stamp and regard .lock file being dead if the app
> does not renew it in certain time period.
And even that isn't guaranteed to work:
Two (or more) processes could be spinning waiting for the timestamp in the
lock file to expire. They then all write the new lock file. They all think they
have the lock, but only one truly does.
You can reduce that risk by:
-- read the lockfile
-- wait for timestamp in the lock file to expire
-- wait a further random fraction of a second
-- read the lock file again: restart if it has an unexpired timestamp (cos
someone beat you to it)
-- write the lock file with your timestamp
-- wait a random fraction of a second
-- reread the lock file again: restart if it does not have your timestamp
(because someone came in just after you and grabbed it)
But even then on a very busy machine (which is when all this matters) two or
more processes could set exactly the timestamp, so they could not tell who
owns the lock file from the expiry timestamp alone.
To get around that, you need a guaranteed unique id (GUID). Write that to the
lock file along with the timestamp. Then, when you reread the lock file, a
changed GUID tells you you do not own the lock file
Which simply opens a further problem of how you get a GUID. IP address is not
sufficient (a caller may have multiple requests on the go).
Something like:
guid: 0
attempt [guid: 1+ load %guid-file.txt]
write %guid-file.txt guid
would work, except you've now pushed the problem back to ensuring serialised
access to %guid-file.txt. And for that, you need a lock file.
Moral: attempting to use a non-locking file system to make an inter-process
lock file is not easy.
It can be done, but you need to accept a level of risk as the locking
mechanism is never going to be foolproof.
Sunanda.
--
To unsubscribe from the list, just send an email to
lists at rebol.com with unsubscribe as the subject.
