Not all online CPUs may be available for the current process,
especially when CPU affinity is involved. In such cases too many
threads will be created, which will unnecessarily compete for CPU
time.
Use sched_getaffinity() (if available) to determine the correct
number of threads to create.
In read_thread(), in the "Do we need this block?" block, it failed
to advance to the next wanted_t when w->end is exactly equal to uend.
In the particular case I looked at, this resulted in read_thread()
erroneously putting two blocks into the queue (pipeline_split(),
read.c:570) instead of one.
This resulted in a subsequent crash in tar_read() at read.c:660,
where gArWanted was null (when clearly the code does not expect it
to be null at that point).
My use case:
I have several hundred large .tar.xz files (created by pixz). Each
archive contains over 200k files. I frequently need to extract a lot
of files from each archive, but not all files, only a specific subset.
So I am making heavy use of the -x option to pixz.
Architectures like SPARC do not allow unaligned accesses. Avoid them by
memcpy()ing the data to an aligned buffer. On x86 systems where
unaligned loads are fast, the memcpy() will be compiled away and the
same code generated as before.
Current logic does not work when system does not have
sys/endian.h, since it tried to reuse the cached results
from first try of detecting htole64 in sys/endian.h which is
'no' and hence the second try to look into endian.h also
comes out negative.
So we check for header and then run the test for symbols
and these symbols are not standard and we need to define _GNU_SOURCE
for it to work, this issue is exposed by systems using musl e.g.
Signed-off-by: Khem Raj <raj.khem@gmail.com>