Re: new rust

[Havard Eidnes <he%NetBSD.org@localhost>]

>>                            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