>> for i in 0..u64::MAX { >> match libc::_cpuset_isset(i, set) { >> [...] >> but ... under which conditions would it seg-fault inside that >> function? > > What's does the Rust impl. of _cpuset_isset() look like? Does it > take ints by any chance and you're passing a u64 to it here. A C > compiler will complain if you use `-m32', but, that's all. Don't > know how the Rust FFI will handle this. That's all I can think > of...
The relevant rust definitions were (from vendor/libc/src/unix/bsd/netbsdlike/netbsd/mod.rs): pub type cpuid_t = u64; extern "C" { pub fn _cpuset_isset(cpu: cpuid_t, set: *const cpuset_t) -> ::c_int; } Of these, the cpuid_t was wrong, because in C it is typedef unsigned long cpuid_t; (from <sys/types.h>), and that's a 32-bit type on ILP32 ports. On such systems, seen from the 32-bit "actual" libc side, this would cause rust to do the equivalent of _cpuset_isset(0, NULL), which is of course going to cause an immediate NULL pointer de-reference. This is now all on the way to be fixed, since this pull request has been accepted and applied upstream: https://github.com/rust-lang/libc/pull/3386 and I've applied this patch to the various "rust libc*" versions vendored inside rust, and have re-built the 1.72.1 bits with this fix as well. >> Debugging the C program reveals that pthread_getaffinity_np() has >> done exactly nothing to the "cset" contents as near as I can >> tell, the "bits" entry doesn't change. > > pthread_getaffinity_np() _can_ be used to get the no. of "online" > CPUs on both Linux and FreeBSD, but it looks (from my perusal just > now) like threads default to no affinity on NetBSD and the scheduler > just picks whatever CPUs available for it--unless the affinity is > explicitly set, in which case it's inherited. > > I think you should just use sysconf(_SC_NPROCESSORS_ONLN) or the > equivalent on NetBSD. That threads default to no affinity on NetBSD matches what I'm seeing and hearing. However, the affinity set *can* be tweaked by schedctl (which appears to require root privileges). The fallback code in rust already does as you suggest: if the probe for the number of CPUs the thread has affinity to is 0, the code probes for _SC_NPROCESSORS_ONLN, and if that returns < 1, then probes for HW_NCPU. Regards, - HÃ¥vard