README

   1 libev is a high-performance event loop/event model with lots of features.
   2 (see benchmark at http://libev.schmorp.de/bench.html)
   3
   4    Homepage: http://software.schmorp.de/pkg/libev
   5    E-Mail: libev@lists.schmorp.de
   6    Library Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod
   7
   8    It is modelled (very losely) after libevent and the Event perl module,
   9    but aims to be faster and more correct, and also more featureful. And
  10    also smaller. Yay.
  11
  12 ABOUT THIS DISTRIBUTION
  13
  14    If you downloaded the libevent+libev distribution of libev, you will
  15    find it looks very much like libevent. In fact, the distributed libev
  16    tarballs are indeed libevent tarballs patched up with the libev
  17    event core, taking the evbuffer, evtag, evdns and evhttpd parts from
  18    libevent (they use the libevent emulation inside libev). Configure and
  19    Makefile stuff is also a more or less direct copy of libevent, and are
  20    maintained by the libevent authors.
  21
  22    If you downloaded the libev distribution (without libevent), then
  23    you only get the core parts of the library, meaning http and dns
  24    client/server code and similar things are missing. Only the core event
  25    loop is included.
  26
  27    If you are looking for an easily embeddable version, I recommend using
  28    the libev standalone distribution or the CVS repository.
  29
  30    Examples of programs that embed libev: the EV perl module,
  31    rxvt-unicode, gvpe (GNU Virtual Private Ethernet) and deliantra
  32    (http://www.deliantra.net).
  33
  34 DIFFERENCES AND COMPARISON TO LIBEVENT
  35
  36    The comparisons below are relative to libevent-1.3e.
  37
  38    - multiple watchers can wait for the same event without deregistering others,
  39      both for file descriptors as well as signals.
  40      (registering two read events on fd 10 and unregistering one will not
  41      break the other).
  42
  43    - fork() is supported and can be handled
  44      (there is no way to recover from a fork with libevent).
  45
  46    - timers are handled as a priority queue (important operations are O(1))
  47      (libevent uses a much less efficient but more complex red-black tree).
  48
  49    - supports absolute (wallclock-based) timers in addition to relative ones,
  50      i.e. can schedule timers to occur after n seconds, or at a specific time.
  51
  52    - timers can be repeating (both absolute and relative ones).
  53
  54    - absolute timers can have customised rescheduling hooks (suitable for cron-like
  55      applications).
  56
  57    - detects time jumps and adjusts timers
  58      (works for both forward and backward time jumps and also for absolute timers).
  59
  60    - race-free signal processing
  61      (libevent may delay processing signals till after the next event).
  62
  63    - more efficient epoll backend
  64      (stopping and starting an io watcher between two loop iterations will not
  65      result in spurious epoll_ctl calls).
  66
  67    - usually less calls to gettimeofday and clock_gettime
  68      (libevent calls it on every timer event change, libev twice per iteration).
  69
  70    - watchers use less memory
  71      (libevent watcher on amd64: 152 bytes, libev native: <= 56 bytes, libevent emulation: 144 bytes).
  72
  73    - library uses less memory
  74      (libevent allocates large data structures wether used or not, libev
  75      scales all its data structures dynamically).
  76
  77    - no hardcoded arbitrary limits
  78      (libevent contains an off-by-one bug and sometimes hardcodes limits).
  79
  80    - libev separates timer, signal and io watchers from each other
  81      (libevent combines them, but with libev you can combine them yourself
  82      by reusing the same callback and still save memory).
  83
  84    - simpler design, backends are potentially much simpler
  85      (in libevent, backends have to deal with watchers, thus the problems with
  86      wildly different semantics between diferent backends)
  87      (epoll backend in libevent: 366 lines no caching, libev: 90 lines full caching).
  88
  89    - libev handles EBADF gracefully by removing the offending fds.
  90
  91    - libev communicates errors to the callback, libevent to the
  92      event adder or not at all.
  93
  94    - doesn't rely on nonportable BSD header files.
  95
  96    - an event.h compatibility header exists, and can be used to run a wide
  97      range of libevent programs unchanged (such as evdns.c).
  98
  99    - win32 compatibility for the core parts.
 100      (the backend is fd-based as documented and on other platforms,
 101      not handle-based like libevent, and can be used for both winscoket environments
 102      and unix-like ones).
 103
 104    - libev can be embedded easily with or without autoconf support into
 105      other programs, with no changes to the source code necessary.
 106
 107    - the event core library (ev and event layer) compiles and works both as
 108      C and C++.
 109
 110    - a simple C++ wrapper that supports methods as callbacks exists.
 111
 112    - a full featured and widely used perl module is available.
 113
 114    whats missing?
 115
 116    - no event-like priority support at the moment (the ev priorities work
 117      differently, but you can use idle watchers to get a similar effect).
 118
 119 AUTHOR
 120
 121    libev was written and designed by Marc Lehmann and Emanuele Giaquinta.
 122
 123    The following people sent in patches or made other noteworthy
 124    contributions to the design (if I forgot to include you, please shout
 125    at me, it was an accident):
 126
 127    W.C.A. Wijngaards
 128    Christopher Layne
 129    Chris Brody
 130