ubik: don't rely on timeout value after select()

The value of timeout after a select() call should be considered
undefined; relying on its value is not portable.
Since IOMGR_Select doesn't modify the timeout it is given, the
intention of the code seems to be to wait for gradually increasing
timeout values, starting at 50ms.  At least under Linux, the
timeout gets set to 0 by select() if it waited for the full specified
time, resulting in a much shorter maximum possible wait period.

Initialize the timeout value for each loop according to the existing
logic, to get consistent behaviour between the lwp and pthreaded code.

Change-Id: I8d3e90fe4e94a378401dd0a6fb7d77266ec09e5a
Reviewed-on: http://gerrit.openafs.org/4441
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Reviewed-by: Derrick Brashear <shadow@dementia.org>

diff --git a/src/ubik/recovery.c b/src/ubik/recovery.c
index bc8509c..550e8eb 100644 (file)
--- a/src/ubik/recovery.c
+++ b/src/ubik/recovery.c
@@ -759,17 +759,18 @@ urecovery_Interact(void *dummy)
            if (ubik_dbase->flags & DBWRITING) {
                struct timeval tv;
                int safety = 0;
-               tv.tv_sec = 0;
-               tv.tv_usec = 50000;
+               long cur_usec = 50000;
                while ((ubik_dbase->flags & DBWRITING) && (safety < 500)) {
                    DBRELE(ubik_dbase);
                    /* sleep for a little while */
+                   tv.tv_sec = 0;
+                   tv.tv_usec = cur_usec;
 #ifdef AFS_PTHREAD_ENV
                    select(0, 0, 0, 0, &tv);
 #else
                    IOMGR_Select(0, 0, 0, 0, &tv);
 #endif
-                   tv.tv_usec += 10000;
+                   cur_usec += 10000;
                    safety++;
                    DBHOLD(ubik_dbase);
                }