lockfile: replace random() by rand()

There you have it: Look the other way for a while, and people start using exotic stuff... ;)

This is a build breakage of master on Windows. There are also a few new test suite failures. On of them is in t1404#2, indicating that a DF conflict takes a different error path. I haven't debugged, yet. The lock file retry test fails, too. I'll report back as time permits.

 lockfile.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

lockfile.c +2 -2

index 5a93bc7..ee5cb01 100644
@@ -191,7 +191,7 @@ static int lock_file_timeout(struct lock_file *lk, const char *path,
 		return lock_file(lk, path, flags);
 
 	if (!random_initialized) {
-		srandom((unsigned int)getpid());
+		srand((unsigned int)getpid());
 		random_initialized = 1;
 	}
 

@@ -218,7 +218,7 @@ static int lock_file_timeout(struct lock_file *lk, const char *path,
 
 		backoff_ms = multiplier * INITIAL_BACKOFF_MS;
 		/* back off for between 0.75*backoff_ms and 1.25*backoff_ms */
-		wait_us = (750 + random() % 500) * backoff_ms;
+		wait_us = (750 + rand() % 500) * backoff_ms;
 		sleep_microseconds(wait_us);
 		remaining_us -= wait_us;

Quoted 2 lines · Johannes Sixt

There you have it: Look the other way for a while, and people start using exotic stuff... ;)

Is it exotic to have random/srandom? Both are in POSIX and 4BSD; admittedly rand/srand are written down in C89 and later, so they might be more portable, but I recall the prevailing wisdom is to favor random over rand for quality of randomness and portability, so I am wondering if it may be a better approach to keep the code as-is and do a compat/random.c based on either rand/srand (or use posix sample implementation [*1*]).

[Reference]

*1* http://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html

Quoted 22 lines

This is a build breakage of master on Windows. There are also a few new test suite failures. On of them is in t1404#2, indicating that a DF conflict takes a different error path. I haven't debugged, yet. The lock file retry test fails, too. I'll report back as time permits.

  lockfile.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

lockfile.c +1 -1

index 5a93bc7..ee5cb01 100644
@@ -191,7 +191,7 @@ static int lock_file_timeout(struct lock_file *lk, const char *path,
  		return lock_file(lk, path, flags);
 
  	if (!random_initialized) {
-		srandom((unsigned int)getpid());
+		srand((unsigned int)getpid());
  		random_initialized = 1;
  	}
 

lockfile.c static int lock_file_timeout(struct lock_file *lk, const char *path, · line 223

Quoted 8 lines

lockfile.c +1 -1

@@ -218,7 +218,7 @@ static int lock_file_timeout(struct lock_file *lk, const char *path,
 
  		backoff_ms = multiplier * INITIAL_BACKOFF_MS;
  		/* back off for between 0.75*backoff_ms and 1.25*backoff_ms */
-		wait_us = (750 + random() % 500) * backoff_ms;
+		wait_us = (750 + rand() % 500) * backoff_ms;
  		sleep_microseconds(wait_us);
  		remaining_us -= wait_us;

Am 30.05.2015 um 19:12 schrieb Junio C Hamano:

Quoted 5 lines

Quoted 2 lines · Johannes Sixt

There you have it: Look the other way for a while, and people start using exotic stuff... ;)

Quoted 7 lines

Is it exotic to have random/srandom? Both are in POSIX and 4BSD; admittedly rand/srand are written down in C89 and later, so they might be more portable, but I recall the prevailing wisdom is to favor random over rand for quality of randomness and portability, so I am wondering if it may be a better approach to keep the code as-is and do a compat/random.c based on either rand/srand (or use posix sample implementation [*1*]).

For our purposes here, the linear congruence of rand() is certainly sufficient. At this time, compatibility functions for random/srandom would just mean a lot of work for little gain.

On 06/04/2015 10:40 AM, Johannes Sixt wrote:
We *certainly* don't require high-quality random numbers for this application. Regarding portability, there is one definite point in favor of rand() (it's available on Windows) vs. Junio's recollection that random() might have portability advantages, presumably on other platforms.

Maybe the easiest thing would be to switch to using rand() and see if the OS/2 and VMS users complain ;-)

The first patch is the same that I posted earlier. It fixes a build failure on Windows on master due to missing random/srandom.

The remaining 3 patches replace the select() invocation that waits for a short time period by the version with poll() that we already use in help.c. This is necessary because a select() call where all three sets of file descriptors are empty is not supported on Windows.

Johannes Sixt (4):
lockfile: replace random() by rand()
help.c: wrap wait-only poll() invocation in sleep_millisec()
lockfile: convert retry timeout computations to millisecond
lockfile: wait using sleep_millisec() instead of select()

 cache.h    |  1 +
 help.c     |  2 +-
 lockfile.c | 31 +++++++++----------------------
 wrapper.c  |  5 +++++
 4 files changed, 16 insertions(+), 23 deletions(-)

The remaining 3 patches replace the select() invocation that waits for a short time period by the version with poll() that we already use in help.c. This is necessary because a select() call where all three sets of file descriptors are empty is not supported on Windows.

Johannes Sixt (4):
lockfile: replace random() by rand()
help.c: wrap wait-only poll() invocation in sleep_millisec()
lockfile: convert retry timeout computations to millisecond
lockfile: wait using sleep_millisec() instead of select()

 cache.h    |  1 +
 help.c     |  2 +-
 lockfile.c | 31 +++++++++----------------------
 wrapper.c  |  5 +++++
 4 files changed, 16 insertions(+), 23 deletions(-)