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 Wed, 28 May 2008 07:41:29 GMT
Andrew Stitcher escribió:
> On Tue, 2008-05-27 at 09:13 +0200, Manuel Teira wrote:
>   
>> ...
>> 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])
>>   fi
>> fi
>>
>> 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:
>>
>> if EPOLL
>>   posix_plat_src += qpid/sys/epoll/EpollPoller.cpp
>> else
>>   posix_plat_src += qpid/sys/sol-ecf/SolECFPoller.cpp
>> endif
>>
>>
>> Do you agree with this type of approach?
>>     
>
> This looks about right. The only comment I'd make is that it's not
> really a binary epoll/solecf thing, so an approach that more easily
> allows us to add in say kqueue (for FreeBSD) and poll (for everyone else
> posix) approaches would be favoured (by mo at least).
>
> In practice it will be a combined uname/version/header/library check I'd
> guess.
>
> I think that the only user visible switch to configure should be to
> select posix as against platform specific. So having
> --with-epoll/--with-kqueue/--with-ecf is not an option I like. I'd go
> for --with-posix-only for the case that we want poll even though we've
> detected that the platform supports something more efficient.
>
> As an aside, unless you know you've got Solaris 10 or better you will
> need to implement something poll() or /dev/poll based as well. In which
> case can I encourage you to do a poll() port as it would be generally
> useful to anyone with any Unix like system.
>   
I totally agree with your approach. Actually, the posix poll interface 
is the most generic, and then, we would have specific mechanisms in 
different OSs. So, perhaps the configure.ac stuff would automatically 
try to guess the better option based in the $host variable (instead of 
the uname I was proposing, and so, providing some hope for cross 
compilations), something like (pseudocode) :
POLLING_IMPL=None
case *sun-solaris2.10)
  - Try to locate port.h && POLLING_IMPL=sol-ecf
  - Else POLLING_IMPL=posix-poll
case *sun-solaris*)
  - POLLING_IMPL=posix-poll
case *linux*)
  - Try to locate sys/epoll.h && POLLING_IMPL=linux-epoll
  - Else POLLING_IMPL=posix-poll
case *bsd*)
  - Try to locate kqueue.h or whatever && POLLING_IMPL=bsd-kqueue
  - Else POLLING_IMPL=posix-poll
case *windows*)
  - Whatever mechanism is used in windows && POLLING_IMPL=windows-whatever

After this, a comparison with the set of existing polling 
implementations would be nice, to decide if we can follow on or we just 
have to throw an error:
case $POLLING_IMPL in
  None)
  AC_MSG_ERROR([No polling mechanism detected for $host])
  ;;
  posix-poll)
  bsd-kqueue)
  windows-whatever)
  AC_MSG_ERROR([No $POLLING_IMPL mechanism implemented yet. Please 
contrib one])
  ;;
  linux-epoll)
  AM_CONDITIONAL([LINUX_EPOLL], [1])
  ;;
  solaris-ecf)
  AM_CONDITIONAL([SOLARIS_ECF], [1])
esac

Then, in the sources Makefile.am, we would add the right sources for the 
selected epoll mechanism.

Regards.

 
> Andrew
>
>
> .
>
>   


Mime
View raw message