Alan Conway escribió:
On Wed, 2008-06-25 at 11:12 +0200, Manuel Teira wrote:
Hello. After a pair of weeks dealing with random, uninteresting stuff,
I'm back to the solaris port effort. I would like to wake up this issue
again, since it's a stopper for the solaris testing I'm trying to do.
After all this discussion, what seems to be true, is:
1.-The static initialization order is not the desired one.
2.-Inlining the Mutex.h annonymous code in every Mutex usage, produces
multiple instances of onceControl and mutexattr, whereas the intended
behaviour was to have single instances, to be shared across the code.
3.-About the PODMutex discussion, it is not needed here, since the
pthread_once_t usage is giving us the desired "one-shot" behaviour.
It was also said, that fixing #2 could lead to get #1 fixed. Anyway,
what is the recommended technique to "force" static initialization if
having #2 fixed is not helping?
Just committed a fix that removes the need for a global object with a
constructor so should fix any init order problems. Also took this code
out of line so it's genuinely once, not once-per-compilation-unit. Shout
if it doesn't fix the problem or creates any new ones.
Great, it got fixed!!
Most of the tests are passing now, but running the federation tests the
old dynamic_cast monster related with the Sun compiler bug arises again.
The problem was due to AsynchConnector being implemented in terms of
DispatchHandle, so, I had to change that inheritance to be public also.
I would like to show you how I've handled this workaround, to see if
this is an acceptable way to do it:
class AsynchConnector :
//Bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6710638
//Should be private inheritance
#ifdef __SUNPRO_CC
public
#else
private
#endif
DispatchHandle {
public:
...
The same for AsynchIO. This way, we will only use that inheritance when
using the Sun Studio compiler, at least while that bug doesn't get
fixed. Perhaps we should vote for it to get fixed. ;-)
Also, I would like to know what is the state of the JIRA issues I
submitted for the solaris port (QPID-1132 and QPID-1133), I mean, did
you have time to look at them, are there any problem with them,...?
I have another bunch of changes, most related with inclusion
differences. Perhaps they could be added without wrapping them in a
#ifdef clause, but I'm not sure. My plan is to open a new JIRA for those
changes, and expose them to your consideration. What do you think? (I'm
talking about this kind of modifications) :
-bash-3.00$ svn diff ../../src/qpid/sys/posix/AsynchIO.cpp
Index: ../../src/qpid/sys/posix/AsynchIO.cpp
===================================================================
--- ../../src/qpid/sys/posix/AsynchIO.cpp (revision 671815)
+++ ../../src/qpid/sys/posix/AsynchIO.cpp (working copy)
@@ -19,6 +19,10 @@
*
*/
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
#include "qpid/sys/AsynchIO.h"
#include "qpid/sys/Time.h"
@@ -31,6 +35,11 @@
#include <signal.h>
#include <errno.h>
+#ifdef SUNOS
+//strerror, memmove prototypes
+#include <string.h>
+#endif
+
#include <boost/bind.hpp>
using namespace qpid::sys;
Do you agree with this way to handle it, or should we just include
string.h directly? Perhaps somebody should test all these changes on a
linux box, before deciding to add them with or without the #ifdef wrapping.
Best regards.
--
Manuel.
Cheers,
Alan.
