On 7 Nov 2011, at 14:52, Jonathan Wakely wrote:
On 7 November 2011 14:40, Iain Sandoe wrote:
so there's a reason to use the systlbyname (and use hw.logicalcpu or
similar, maybe).
[unless that's just a buggy sysconf]
Well if that's how they want to play it then I'm not even going to
think abo
On 7 November 2011 14:40, Iain Sandoe wrote:
>
> On 7 Nov 2011, at 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::
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 o
On 7 Nov 2011, at 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_
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 pth
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
On 7 November 2011 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
>
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 hard
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 suppo
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
* acinclude.m4 (GLIBCXX_CHECK_SC_NPROC_ONLN): Define.
(G
I am currently working on a patch for OpenBSD.I wrote a some autoconf
tests for mingw/*BSD.
2011/11/7 Jonathan Wakely :
> I'm testing my suggestion on a netbsd machine, I'd be grateful for
> darwin testing once I've committed it, which I expect to be later
> today.
>
I'm testing my suggestion on a netbsd machine, I'd be grateful for
darwin testing once I've committed it, which I expect to be later
today.
On Nov 1, 2011, at 10:13 AM, Jonathan Wakely wrote:
>> I suspect on some systems, this would be a runtime value so, no fixed
>> constant could ever work.
>
> It's a constant for identifying the sysctl, not a constant for the
> number of processors e.g. (untested)
Ah, never mind, ignore me.
On 1 November 2011 17:06, Mike Stump wrote:
> On Nov 1, 2011, at 8:55 AM, Jonathan Wakely wrote:
>> Is there a reason you used "hw.ncpu" not the constant HW_NCPU ?
>
> I suspect on some systems, this would be a runtime value so, no fixed
> constant could ever work.
It's a constant for identi
On Nov 1, 2011, at 8:55 AM, Jonathan Wakely wrote:
> Is there a reason you used "hw.ncpu" not the constant HW_NCPU ?
I suspect on some systems, this would be a runtime value so, no fixed
constant could ever work.
On 1 November 2011 16:01, Jonathan Wakely wrote:
> On 1 November 2011 15:57, niXman wrote:
>>> What header is required for pthread_num_processors_np?
>> pthread.h
>
> OK.
>
> This assumes that Pthreads is the only abstraction available on __hpux
> (i.e. that if _GLIBCXX_HAS_GTHREADS is true then we
On 1 November 2011 15:57, niXman wrote:
>> What header is required for pthread_num_processors_np?
> pthread.h
OK.
This assumes that Pthreads is the only abstraction available on __hpux
(i.e. that if _GLIBCXX_HAS_GTHREADS is true then we have already
included ):
+#if defined(PTW32_VERSION) || \
+
Ok. I correct it.
2011/11/1 Jonathan Wakely :
> I've put gcc-patches@ back in the CC list and removed gcc@
>
>
> On 1 November 2011 15:35, niXman wrote:
>>> Er, the macro _GLIBCXX_NPROCS already handles
>>> the case sysconf(_SC_NPROCESSORS_ONLN).
>>> It looks like you actually want to remove the m
> What header is required for pthread_num_processors_np?
pthread.h
> Also, you should include before calling sysctlbyname.
On the right - yes.
sysctlbyname() implicitly included in some header files.
Is there a reason you used "hw.ncpu" not the constant HW_NCPU ?
On 1 November 2011 15:47, Jonathan Wakely wrote:
> I've put gcc-patches@ back in the CC list and removed gcc@
Oops, *now* I've removed gcc@
> On 1 November 2011 15:35, niXman wrote:
>>> Er, the macro _GLIBCXX_NPROCS already handles
>>> the case sysconf(_SC_NPROCESSORS_ONLN).
>>> It looks like yo
I've put gcc-patches@ back in the CC list and removed gcc@
On 1 November 2011 15:35, niXman wrote:
>> Er, the macro _GLIBCXX_NPROCS already handles
>> the case sysconf(_SC_NPROCESSORS_ONLN).
>> It looks like you actually want to remove the macro
>> _GLIBCXX_NPROCS completely.
>
> Fixed.
No, this
With what exactly do you don't accept this patch?
2011/11/1 Jonathan Wakely :
> On 1 November 2011 11:54, Marc Glisse wrote:
>> On Tue, 1 Nov 2011, niXman wrote:
>>
>>> diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
>>> index 09e7fc5..6feda4d 100644
>>> --- a/libstdc++-v3/sr
On 1 November 2011 11:54, Marc Glisse wrote:
> On Tue, 1 Nov 2011, niXman wrote:
>
>> diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
>> index 09e7fc5..6feda4d 100644
>> --- a/libstdc++-v3/src/thread.cc
>> +++ b/libstdc++-v3/src/thread.cc
>> @@ -112,10 +112,20 @@ _GLIBCXX_BEGIN
On Tue, 1 Nov 2011, niXman wrote:
diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
index 09e7fc5..6feda4d 100644
--- a/libstdc++-v3/src/thread.cc
+++ b/libstdc++-v3/src/thread.cc
@@ -112,10 +112,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
unsigned int
thread::hardware_concurre
On 11/01/2011 12:33 PM, niXman wrote:
Rechecked.
Stylistically, you are missing a lot of spaces around the operators, eg:
return (count > 0) ? count : 0;
also, patches are always submitted with a ChangeLog entry.
Do you have already a Copyright assignment in place? I'm asking in
general,
Rechecked.
diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
index 09e7fc5..6feda4d 100644
--- a/libstdc++-v3/src/thread.cc
+++ b/libstdc++-v3/src/thread.cc
@@ -112,10 +112,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
unsigned int
thread::hardware_concurrency() noexcept
{
-
On Oct 31, 2011, at 2:10 PM, niXman wrote:
> This is patch is implement the std::thread::hardware_concurrency().
[ general comment ] Ick, this isn't what I'd call clean. Maybe a porting
header inclusion that defines a static inline pthread_num_processors_np when on
those system that don't have
On 10/31/2011 02:10 PM, niXman wrote:
> +#elif definen(_GLIBCXX_USE_GET_NPROCS)
Typo.
r~
Hi,
> This is patch is implement the std::thread::hardware_concurrency().
> Tested on pthreads-win32/winpthreads on windows OS, and on Linux/FreeBSD.
Please send library patches to the library mailing list too. Also, always parch
mainline first: actually in the latter the function is alread impl
Hi all.
This is patch is implement the std::thread::hardware_concurrency().
Tested on pthreads-win32/winpthreads on windows OS, and on Linux/FreeBSD.
diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
index 09e7fc5..3eacb06 100644
--- a/libstdc++-v3/src/thread.cc
+++ b/libstd
31 matches
Mail list logo
