Re: implementation of std::thread::hardware_concurrency()

[Iain Sandoe <developer at sandoe-acoustics dot co dot uk>]

On 7 Nov 2011, at 14:38, Jonathan Wakely wrote:

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

from Darwin 9 onwards I believe so ..  (don't actually have a copy of  
Darwin11 yet).

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