* Fix Result Report Race Condition in Pipe-based Context Switching Test
Ensure all report() calls yield correct information.
* Simplify code in Pipe-based Context Switching Test
Remove un-needed iter1 variable
Addresses "slave write failed: Broken pipe; aborting"
There are two processes that are alternating reading and writing
a sequence number of sizeof(unsigned long) size, which is 4 bytes
on 32-bit ILP32 ABI and 8 bytes on 64-bit LP64 ABI. The read/write
passing of incrementing sequence number occurs in infinite loop
until an alarm signals each process. There is a race condition
where a signal delivered to one process might close the pipes while
the second process was still attempting to read or write from the
pipes, and before the second process was interrupted with SIGALRM.
This patch fixes the race condition that occurs at the end of the
test run, after the first SIGALRM is delivered.
This patch does not address the paranoid possibility that read() or
write() of 4 or 8 bytes might theoretically be a partial read() or
write(), but that is extremely unlikely except in the case of a signal
being delivered, and the only signal expected is SIGALRM, and the
processing of SIGALRM by report() function does not return. (This
patch adds code to ignore SIGPIPE, so SIGALRM is the only expected
signal.)
github: fixes#1
const correctness
format string safety
remove assigned, but unused, variables
fix arguments to execl()
remove defined but unused warnings (for code used only by some tests)
barusan's patch mostly retains compatibility with linux, but
unconditionally used machdep instead of /proc/cpuinfo
This attempts to merge the patch without harming behaviour on linux by
detecting the darwin platform and using machdep there but restores
/proc/cpuinfo elsewhere.
Quoting original author of this patch:
Simply un-limits the 'misc' and 'system' suites.
Half-related thoughts about testing quality:
I'm curious why there's a shell1, shell8, and shell16 set of tests. Aren't the
latter two equivalent to './Run -c 8 shell1' and './Run -c 16 shell1'? I think
shell8 and shell16 are pointless if this is the case.
At the very least, I think shell8 should be out of the default run (the $index
set), because it will essentially give a misleading number if you have more
than a single core in the system. Isn't the purpose of the serial run to
essentially measure how well the system performs on single-threaded activities?
Or perhaps to measure how well a single core performs? Having 'shell8' in the
$index set artificially inflates the score for serialized runs and artificially
damages the score during maxed-out parallelized runs. If you are actually
interested in seeing how well 'shell8' does on exactly one core, shouldn't you
do the equivalent of 'taskset 1' on it, forcing the child processes to stay on
that single core?
End of quote.
Signed-off-by: Carlos L. Torres <carlos.torres@rackspace.com>
