[zeromq-dev] [PATCH] detect (select poll epoll_ctl kqueue) at configure time

Martin Lucina mato at kotelna.sk
Mon Oct 4 15:36:58 CEST 2010


Pieter,

sorry, I got confused, you started a new thread which is why I didn't
realise this was related to the "disabling epoll()" thread.

ph at imatix.com said:
> index f8d2e5e..3b4fafb 100644
> --- a/configure.in
> +++ b/configure.in
> @@ -365,6 +365,7 @@ AC_SUBST(LIBZMQ_EXTRA_LDFLAGS)
>  # Checks for library functions.
>  AC_TYPE_SIGNAL
>  AC_CHECK_FUNCS(perror gettimeofday memset socket getifaddrs freeifaddrs)
> +AC_CHECK_FUNCS(select poll epoll_ctl kqueue)
> 
>  AC_OUTPUT(Makefile src/Makefile doc/Makefile
>      perf/Makefile src/libzmq.pc \

I can kind of see where you're going with this; you want to detect the
polling mechanism in a generic way based off the availability of a system
call rather than based off a check for a particular OS. This is how things
would normally be done with autoconf but it's not been done that way with
0MQ and I'd rather not change this now unless we get added value out of it;
see below.

Your change doesn't actually do anything by itself; it's poller.hpp (for
zmq::poller_t) and zmq.cpp (for zmq_poll()) that determine what polling
mechanism to use internally. You have to change those files to use the
appropriate implementation based on your generic check rather than on an
ifdef based off the OS type.

In any case, all of this is moot anyway since this only determines what
call is available at *compile time*; i.e. provided by the C library of the
cross-compiler target. There is no way to determine if that call will
actually be supported by the target host kernel. So the original poster
having the issue of the code not running at *runtime* on Linux 2.4.x should
just build with -DZMQ_FORCE_POLL in CXXFLAGS.

-mato



More information about the zeromq-dev mailing list