On Tue, 2008-08-19 at 14:15 +0200, Manuel Teira wrote:
> I forgot to comment another weird issue I suffered:
>
> The first version of the solaris qpid::sys::SystemInfo::concurrency was
> just returning -1, as I was not sure about how to implement it for
> solaris, and the code in the common version was:
>
> long SystemInfo::concurrency() {
> #ifdef _SC_NPROCESSORS_ONLN // Linux specific.
> return sysconf(_SC_NPROCESSORS_ONLN);
> #else
> return -1;
> #endif
> }
>
> So, as it was marked as Linux specific, my first version was:
>
> long SystemInfo::concurrency() {
> return -1;
> }
>
> What I got using this version was a funny "Out of memory" error. The
> problem was actually in qpid::broker::Broker, that is using the
> concurrency() value to calculate the number of working threads, as:
>
> int c = sys::SystemInfo::concurrency();
> workerThreads=c+1;
>
> So, with concurrency returning -1, workerThreads equals 0, and later, in
> Broker::run()
>
>
> int numIOThreads = config.workerThreads;
> std::vector<Thread> t(numIOThreads-1);
>
> Leading to an attempt to create a vector of 0xffffffffffffffff entries
> in my 64 bits sparc executable.
>
> Later, I discovered that _SC_NPROCESSORS_ONLN also exists on Solaris (it
> seems it's actually posix compliant) and changed the solaris
> implementation, as part of the localaddrs patch. However, I think that
> perhaps the value of SystemInfo::concurrency() should be used more
> prudently or perhaps the value to return when an architecture has no way
> to provide the number of processors should be 1, as a safe value.
Yes, this is my stupid bug - I'd go with returning 1 if no better
estimate is available. Note this means on multi-cpu solaris boxes it
will be important to set --worker-threads manually to something
approximating the number of available cores to get good performance.
Sorry about that!
