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