[ John Gilmore writes: ]
>
> Exponential backoff is the preferred approach -- e.g. back off 1
> second the first time, 2 the second, 4 the third, 8 the fourth, etc.
Let's see, 2**600 is Really Big (TM) (181 digits according to bc). I
think sleep() might have a problem with that. :-) But I'm not sure
everyone backing off at the same rate, whether exponential, linear,
quadratic, or whatever, would help as much as a random sleep.
I know this has all been discussed before (sorry, I don't remember
exactly what Brent (? somebody) wanted to do about file locking, but I
think it was to have queued locks so the request order was preserved and
all the fighting for the lock was eliminated), but that implementation
was definitely on hold for a later release (2.x?). As for file locking,
Brent recently commented on that to reiterate how that isn't as portable
as lock files. So before someone tries to slip this into 1.94, let's
take a look at something like this for a quick fix:
srand(time ^ $$); # or some reasonably unique seed
for ($tries = 1; $tries < $retries; $tries++) {
# Try to obtain the lock $retries times, waiting at least 1 second
# after each try
if (&main'shlock("$lockfile")) {
# Got the lock; now try to open the file
$status = open($FH, $fm);
...
# return the success or failure of the open
return($status);
} else {
# didn't get the lock; wait awhile and try again.
sleep(1 + rand(9)); # wait 1 to 10 seconds
}
}
# If we get this far, we ran out of tries on the lock.
I first thought of looping on a fixed time limit, but that won't work
because it makes the number of lock tries indeterminate (possibly zero).
A fixed number of tries makes the time spent vary widely (e.g. 600 tries
could take 600 to 6000 seconds (5 to 50 minutes), not counting time
spent waiting to run), but that seems preferable to unreproducible lock
failures.
--
Dave Wolfe *Not a spokesman for Motorola*
Motorola MMTG 6501 Wm. Cannon Dr. W. OE112 Austin TX 78735-8598
Follow-Ups:
References:
|
|
