auto configuration and eventfd support

Marc Lehmann schmorp at
Sun Apr 6 12:04:53 CEST 2008


I just checked in some changes into the libev cvs that seem noteworthy.

1. in the absence of autoconf support, libev would disable most features
   it cannot reliably detetc via know-to-be existing headerfiles
   (i.e. epoll, inotify etc.)

   current cvs, in the absence of any overriding configuration, will
   instead enable epoll if it detects linux and glibc 2.4+ headers,
   inotify likewise, and will enable eventfd with 2.7 headers.
   this should make embedding easier in some important cases.

   I would be interested to hear about how stable this autodetection is, and
   it would be nice if somebody with knowledge could deliver corresponding
   preprocessor expressions for use with e.g. kqueue and solaris ports.

2. I just hacked in support for linux eventfd (requiring the glibc stub, but
   not the headers, so it should work with glibc 2.7 onwards).

   in my micro-benchmarks, a write/read cycle to a pipe takes ~1800
   cycles, while a read/write to the eventfd takes ~1100 cycles (a
   substantial speed improvement, but I would prefer something in the
   range of 100 cycles of course :->)

   this would mainly speed up ev_async processing once/iteration.

   as this was literally a 20 minute hack (including docs :), I would be
   happy to hear about anybody using it. You can detect its use in strace
   by use of the eventfd syscall or the fact that ev_async's cause 8-byte
   writes to the signal pipe, not 1-byte writes. It cna be forced
   on by defining EV_USE_EVENTFD.


                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_    
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list