On 7 November 2011 14:23, Iain Sandoe wrote: > > On 7 Nov 2011, at 14:16, Jonathan Wakely wrote: > >> On 7 November 2011 14:10, Iain Sandoe wrote: >>> >>> On 7 Nov 2011, at 13:45, Jonathan Wakely wrote: >>> >>>> This provides a working thread::hardware_concurrency on platforms that >>>> support pthread_num_processors_np or the "hw.ncpu" sysctl, but by >>>> testing for the features in configure rather than hardcoding OS macro >>>> tests in thread.cc >>> >>> if the system supports run-time User-controllable core-count then this >>> will >>> not account for that. >> >> Yep. Do you know how to detect the right value in that case? If not >> the alternative is to revert to the previous behaviour of returning >> zero. >> >> (My understanding was that at least some of the options would work for >> that case, NPROCESSORS_ONLN is distinct from _SC_NPROCESSORS_CONF, for >> example) > > Hm. I don't know about the general case - on Darwin it's certainly possible > to get at the information at runtime; > > hw.logicalcpu_max: 4 > hw.logicalcpu: 4 > hw.physicalcpu_max: 4 > hw.physicalcpu: 4 > hw.ncpu = 4 > > and ... switching the control panel to dual CPU .. > > hw.logicalcpu_max: 4 > hw.logicalcpu: 2 > hw.physicalcpu_max: 4 > hw.physicalcpu: 2 > hw.ncpu = 4 > > but, as you say, that would be the implication of "ONLN" vs "CONF" ..
Does Darwin support those sysconf values? AFAICT it doesn't. If not, we could find out the equivalent of HW_NCPU for "hw.logicalcpu" or just use sysctlbyname, but as Apple haven't documented it in the sysctl manpage I don't know if those sysctls are stable or reliable. If someone wants to improve the checks be my guest, as long as it's done via autoconf macros, not by making the macro mess in src/thread.cc any worse.
