Alan Conway escribió:
Manuel Teira wrote:
Gordon Sim escribió:
It looks like the declaration of those methods did not match the
definitions w.r.t const declarations. I checked in a change to both as
r661323 - does that fix it?
.
Great, looking at the method declaration and implementation didn't ever
crossed my mind (too much time programming java, I'm afraid). It's
fixed! Now:
-bash-3.00$ LD_LIBRARY_PATH=/opt/dslap/contrib/lib:. ./qpidd -v
qpidd (qpidc) version 0.2
It all its 64 bits glory:
-bash-3.00$ file qpidd
qpidd: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
linked, not stripped
I will like to send a patch to your consideration, including all the
changes I've made to achieve this. But before, I would like to implement
the Event Completion Framework based poller, as the version I have now
is a dummy one, just trying to reach this point: a valid linked executable.
Thanks a lot and best regards.
Thanks dragging qpid through its first real port :) Don't hesitate to post if
you need any more help. Looking forward to the patch, it's all good stuff.
You're welcome.
I prefer to wait until the Event Completion Framework Poller is done, to
have something not only compiling on solaris, but running also (or kind of).
I've hit another problem, runtime I should say ;-)
Just to summarize, I think the problem is in the initializers for
mutexes classes. It can be reproduced in solaris doing something like this:
#include <stdio.h>
#include <Mutex.h>
int main(int argc, char **argv)
{
qpid::sys::RWlock lock;
}
Running this little program, leads to:
-bash-3.00$ ./mutex
Invalid argument
Assertion failed: 0, file
ws/DSLAP/qpid/trunk/qpid/cpp/src/qpid/sys/posix/Mutex.h, line 175
Abort (core dumped)
The abort is raised in:
RWlock::RWlock() {
QPID_POSIX_ASSERT_THROW_IF(pthread_rwlock_init(&rwlock,
recursiveRWlockattr));
}
And the only way for that assert to fail, is that rwlock and/or the
result of recursiveRWlockattr() are not valid.
I found the way the attributes for locks and mutexes are initialized,
very elegant. But, how come they are sharing the same pthread_once_t?
Never heard about this useful feature before, and reading the man page,
found:
DESCRIPTION
If any thread in a process with a once_control parameter
makes a call to pthread_once(), the first call will summon
the init_routine(), but subsequent calls will not. The
once_control parameter determines whether the associated
initialization routine has been called. The init_routine()
is complete upon return of pthread_once().
So, my suspect was that as classes RecursiveMutexAttr and
RecursiveRWLockAttr are sharing the same pthread_once_t known as
onceControl:
RecursiveMutexattr() {
pthread_once(&onceControl, initMutexattr);
}
RecursiveRWlockattr() {
pthread_once(&onceControl, initRWlockattr);
}
only the first one of them called in one thread, should actually perform
its task.
To check it, I just added a dirty printfs in:
void initMutexattr() {
printf("initMutexattr called\n");
pthread_mutexattr_init(&mutexattr);
pthread_mutexattr_settype(&mutexattr, PTHREAD_MUTEX_RECURSIVE);
}
void initRWlockattr() {
printf("initRWlockattr called\n");
pthread_rwlockattr_init(&rwlockattr);
}
Recompiling and running again my program, led to:
-bash-3.00$ ./mutex
initMutexattr called
Invalid argument
Assertion failed: 0, file
ws/DSLAP/qpid/trunk/qpid/cpp/src/qpid/sys/posix/Mutex.h, line 175
Abort (core dumped)
So, initRWlockAttr is not called, and hence, the rwlockattr member is
not initialized, feeding the bloody assert monster.
So, shouldn't we use different pthread_once_t variables for each of the
initializers?
Even more interesting, how can this work on linux, for example?
Recursive regards.
--
Manuel.
