qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Teira <mte...@tid.es>
Subject Re: qpid (cpp) on solaris + Sun Studio 12
Date Tue, 27 May 2008 07:13:51 GMT
Andrew Stitcher escribió:
> Alan Conway wrote:
>> Manuel Teira wrote:
>>> Hello again. First of all, thanks for all your kind responses and
>>> suggestions in my "Greetings and questions" post. I could have
>>> answered to that post, but I thought that opening a more explicit
>>> thread would be helpful for people searching for information about
>>> this topic.
>>> About the lacking of epoll interface in Solaris, I'm planning an
>>> implementation of qpid::sys::Poller based on the Solaris 10 Event
>>> Completion Framework
>>> (http://developers.sun.com/solaris/articles/event_completion.html).
>> Cool, will be nice to see it. The intended model is to implement your
>> stuff in a src/qpid/sys/solaris directory and add the #ifdefs to
>> select it appropriately.
> In this case it may be only necessary to use conditionals in the
> Makefile.am to select the specific platform code. I think that #ifdefs
> should be avoided where we can do it easily enough.
Yes, my plan was to make something like this:

AC_CHECK_HEADERS([sys/epoll.h],[with_epoll=yes], [with_epoll=no])
if test x$with_epoll = xno; then
  AC_CHECK_HEADERS([port.h],[with_solecf=yes], [with_solecf=no])
  if test x$with_solecf = xno; then
    AC_MSG_ERROR([No supported polling infrastructure found])

AM_CONDITIONAL([EPOLL], [test x$with_epoll = xyes])
AM_CONDITIONAL([SOLECF], [test x$with_solecf = xyes])

in configure.ac. Or perhaps something more $(UNAME) oriented would be 
preferred? I mean, just using the Solaris Event Completion Framework 
when in solaris, instead of that. Anyway, we have to take into account 
that ECF exists since Solaris 10. For previous versions of the OS, they 
had a poll interface.

Then, selecting the appropiate implementation  in the proper Makefile.am:

  posix_plat_src += qpid/sys/epoll/EpollPoller.cpp
  posix_plat_src += qpid/sys/sol-ecf/SolECFPoller.cpp

Do you agree with this type of approach?

>> ...
>>> 3.- It seems to me that this statement in qpid/framing/Blob.h is no
>>> longer true:
>>> /** 0-arg in_place<T>() function, missing from boost. */
>>> template<class T>
>>> typed_in_place_factory0<T> in_place() { return
>>> typed_in_place_factory0<T>(); }
>>> As I'm getting a lot of overloading ambiguities while compiling
>>> gen/qpid/framing/BodyHolder_gen.cpp:
>> [snip]
>>> Same error repeated for all the in_place calls. This is happening
>>> using boost 1.35.0
>>> I'm just guessing that the in_place<T>() is no longer missing from
>>> boost, because the header is a macro-hell, and my brain coredumped
>>> after a fast review.
> Oops, my fault - Steve Hutson already gave us a patch for this (or a
> very similar) issue - I assigned it to me to apply then went away for a
> long weekend! I'll deal with it very soon now I'm back.
Thanks a lot. In the mean time I've applied the fix Alan recommended and 
it's working fine.

Best regards.


> Andrew

View raw message