[EMAIL PROTECTED] wrote: > 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) >
uh, that all sounds crazy and because of what? Because unix can't guarantee you file-lock if you particularly ask for it? What a weak system .... > 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). > what about checksum/secure? Should provide you enough of randomizer .... but two same time values will give you the same result ... maybe you could use checksum/secure/key and randomly generate the key or so :-) -pekr- -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject.
