re: https://bz.apache.org/bugzilla/show_bug.cgi?id=45615
I think it best to follow up here as per suggestions by Yann and Rainer
wherein I can run further tests and experiments to determine what is
happening here in these Niagara class systems.
Firstly, sorry for awaking what seems like a long dead cold bug but it
really isn't a "Large Files not supported" bug as opposed to just a
message that needs to be tweaked. Indeed yes this is a 64 bit build and
so off_t and size_t and going to be 64-bit sized :
int
main(int argc, char *argv[])
{
printf ("\nC\n");
printf ( "sizeof char = %d\n", sizeof (char));
printf ( "sizeof double = %d\n", sizeof (double));
printf ( "sizeof float = %d\n", sizeof (float));
printf ( "sizeof int = %d\n", sizeof (int));
printf ( "sizeof long = %d\n", sizeof (long));
printf ( "sizeof long long = %d\n", sizeof (long long));
printf ( "sizeof short = %d\n", sizeof (short));
printf ( "sizeof void * = %d\n", sizeof (void *));
printf ( "sizeof clock_t = %d\n", sizeof (clock_t));
printf ( "sizeof gid_t = %d\n", sizeof (gid_t));
printf ( "sizeof pid_t = %d\n", sizeof (pid_t));
printf ( "sizeof size_t = %d\n", sizeof (size_t));
printf ( "sizeof ssize_t = %d\n", sizeof (ssize_t));
printf ( "sizeof off_t = %d\n", sizeof (off_t));
printf ( "sizeof time_t = %d\n", sizeof (time_t));
printf ( "sizeof uid_t = %d\n", sizeof (uid_t));
printf ( "sizeof \"\" = %d\n", sizeof (""));
return (EXIT_SUCCESS);
}
C
sizeof char = 1
sizeof double = 8
sizeof float = 4
sizeof int = 4
sizeof long = 8
sizeof long long = 8
sizeof short = 2
sizeof void * = 8
sizeof clock_t = 8
sizeof gid_t = 4
sizeof pid_t = 4
sizeof size_t = 8
sizeof ssize_t = 8
sizeof off_t = 8
sizeof time_t = 8
sizeof uid_t = 4
sizeof "" = 1
So that seems clear.
As for the blocking rand, well hrmmm, not unless I was trying to read a
ton of data from /dev/random wherein :
Devices random(7D)
NAME
random, urandom - Strong random number generator device
SYNOPSIS
/dev/random
/dev/urandom
DESCRIPTION
The /dev/random and /dev/urandom files are special files
that are a source for random bytes generated by the kernel
random number generator device. The /dev/random and
/dev/urandom files are suitable for applications requiring
high quality random numbers for cryptographic purposes.
The generator device produces random numbers from data and
devices available to the kernel and estimates the amount of
randomness (or entropy) collected from these sources. The
entropy level determines the amount of high quality random
numbers that are produced at a given time.
Applications retrieve random bytes by reading /dev/random or
/dev/urandom. The /dev/random interface returns random bytes
only when sufficient amount of entropy has been collected.
If there is no entropy to produce the requested number of
bytes, /dev/random blocks until more entropy can be
obtained. Non-blocking I/O mode can be used to disable the
blocking behavior. The /dev/random interface also supports
poll(2). Note that using poll(2) will not increase the speed
at which random numbers can be read.
etc etc ...
So I would expect that /dev/random may slow down but not by too much
while many other processes are running on the system and in this case
the build system is a single virtual zone inside a machine with a
number of zones. There should be plenty of data. However I have never
run a benchmark. I can certainly run a test for "blocking rand()" as
per http://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html
However I will say that the Apache 2.4.25 server seems to be running
very well with this new apr and apr-util but I am sure we can sort out
this weird test behavior. I certainly have the Sparc hardware sitting
here and can even provide the Oracle Sparc M7 tests if needed.
Dennis
