On Fri, 2008-06-27 at 14:05 +0200, Manuel Teira wrote:
> 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.

I would suggest including them directly. There are many places where we
are picking up system headers we need "by accident" because they are
included in other #include files. Making all the required #includes
explicit is good for portability.

I can commit these changes Monday, if I do stumble across any headers
that are not available on linux that is a good thing as it may highlight
a point were we need some more abstractions in qpid::sys.



Reply via email to