X-Git-Url: https://git.llucax.com/software/libev.git/blobdiff_plain/469af6002e7d33bcc351c1113afb188c3c246b91..0d2fcb8fc814d741c4d4a4ea2d63a02383b8526f:/README

diff --git a/README b/README
index f86fcf6..c614ed4 100644
--- a/README
+++ b/README
@@ -1,69 +1,130 @@
-libev is modelled after libevent (http://monkey.org/~provos/libevent/), but aims
-to be faster and more correct, and also more featureful. Examples:
+libev is a high-performance event loop/event model with lots of features.
+(see benchmark at http://libev.schmorp.de/bench.html)
 
-(comparisons relative to libevent-1.3e and libev-0.00)
+   Homepage: http://software.schmorp.de/pkg/libev
+   E-Mail: libev@lists.schmorp.de
+   Library Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod
 
-- multiple watchers can wait for the same event without deregistering others,
-  both for file descriptors as well as signals.
-  (registering two read events on fd 10 and unregistering one will not
-  break the other)
+   It is modelled (very losely) after libevent and the Event perl module,
+   but aims to be faster and more correct, and also more featureful. And
+   also smaller. Yay.
 
-- fork() is supported and can be handled
-  (there is no way to recover from a fork when libevent is active)
+ABOUT THIS DISTRIBUTION
 
-- timers are handled as a priority queue
-  (libevent uses a less efficient red-black tree)
+   If you downloaded the libevent+libev distribution of libev, you will
+   find it looks very much like libevent. In fact, the distributed libev
+   tarballs are indeed libevent tarballs patched up with the libev
+   event core, taking the evbuffer, evtag, evdns and evhttpd parts from
+   libevent (they use the libevent emulation inside libev). Configure and
+   Makefile stuff is also a more or less direct copy of libevent, and are
+   maintained by the libevent authors.
 
-- supports absolute (wallclock-based) timers in addition to relative ones,
-  i.e. can schedule timers to occur after n seconds, or at a specific time.
+   If you downloaded the libev distribution (without libevent), then
+   you only get the core parts of the library, meaning http and dns
+   client/server code and similar things are missing. Only the core event
+   loop is included.
 
-- timers can be repeating (both absolute and relative ones)
+   If you are looking for an easily embeddable version, I recommend using
+   the libev standalone distribution or the CVS repository.
 
-- detects time jumps and adjusts timers
-  (works for both forward and backward time jumps and also for absolute timers)
+   Examples of programs that embed libev: the EV perl module,
+   rxvt-unicode, gvpe (GNU Virtual Private Ethernet) and deliantra
+   (http://www.deliantra.net).
 
-- can correctly remove timers while executing callbacks
-  (libevent doesn't handle this reliably and can crash)
+DIFFERENCES AND COMPARISON TO LIBEVENT
 
-- race-free signal processing
-  (libevent may delay processing signals till after the next event)
+   The comparisons below are relative to libevent-1.3e.
 
-- less calls to epoll_ctl
-  (stopping and starting an io watcher between two loop iterations will now
-  result in spuriois epoll_ctl calls)
+   - multiple watchers can wait for the same event without deregistering others,
+     both for file descriptors as well as signals.
+     (registering two read events on fd 10 and unregistering one will not
+     break the other).
 
-- usually less calls to gettimeofday and clock_gettime
-  (libevent calls it on every timer event change, libev twice per iteration)
+   - fork() is supported and can be handled
+     (there is no way to recover from a fork with libevent).
 
-- watchers use less memory
-  (libevent on amd64: 152 bytes, libev: <= 56 bytes)
+   - timers are handled as a priority queue (important operations are O(1))
+     (libevent uses a much less efficient but more complex red-black tree).
 
-- library uses less memory
-  (libevent allocates large data structures wether used or not, libev
-  scales all its data structures dynamically)
+   - supports absolute (wallclock-based) timers in addition to relative ones,
+     i.e. can schedule timers to occur after n seconds, or at a specific time.
 
-- no hardcoded arbitrary limits
-  (libevent contains an off-by-one bug and sometimes hardcodes a limit of
-  32000 fds)
+   - timers can be repeating (both absolute and relative ones).
 
-- libev separates timer, signal and io watchers from each other
-  (libevent combines them, but with libev you can combine them yourself
-  by reusing the same callback and still save memory)
+   - absolute timers can have customised rescheduling hooks (suitable for cron-like
+     applications).
 
-- simpler design, backends are potentially much simpler
-  (in libevent, backends have to deal with watchers, thus the problems)
-  (epoll backend in libevent: 366 lines, libev: 90 lines, and more features)
+   - detects time jumps and adjusts timers
+     (works for both forward and backward time jumps and also for absolute timers).
 
-- libev handles EBADF gracefully by removing the offending fds.
+   - race-free signal processing
+     (libevent may delay processing signals till after the next event).
 
-whats missing?
+   - more efficient epoll backend
+     (stopping and starting an io watcher between two loop iterations will not
+     result in spurious epoll_ctl calls).
 
-- evdns, evhttp, bufferevent are missing, libev is only an even library at
-  the moment.
+   - usually less calls to gettimeofday and clock_gettime
+     (libevent calls it on every timer event change, libev twice per iteration).
 
-- no priority support at the moment
+   - watchers use less memory
+     (libevent watcher on amd64: 152 bytes, libev native: <= 56 bytes, libevent emulation: 144 bytes).
 
-- kqueue, poll (libev currently implements epoll and select)
+   - library uses less memory
+     (libevent allocates large data structures wether used or not, libev
+     scales all its data structures dynamically).
 
-- windows support (whats windows?)
+   - no hardcoded arbitrary limits
+     (libevent contains an off-by-one bug and sometimes hardcodes limits).
+
+   - libev separates timer, signal and io watchers from each other
+     (libevent combines them, but with libev you can combine them yourself
+     by reusing the same callback and still save memory).
+
+   - simpler design, backends are potentially much simpler
+     (in libevent, backends have to deal with watchers, thus the problems with
+     wildly different semantics between diferent backends)
+     (epoll backend in libevent: 366 lines no caching, libev: 90 lines full caching).
+
+   - libev handles EBADF gracefully by removing the offending fds.
+
+   - libev communicates errors to the callback, libevent to the
+     event adder or not at all.
+
+   - doesn't rely on nonportable BSD header files.
+
+   - an event.h compatibility header exists, and can be used to run a wide
+     range of libevent programs unchanged (such as evdns.c).
+
+   - win32 compatibility for the core parts.
+     (the backend is fd-based as documented and on other platforms,
+     not handle-based like libevent, and can be used for both winscoket environments
+     and unix-like ones).
+
+   - libev can be embedded easily with or without autoconf support into
+     other programs, with no changes to the source code necessary.
+
+   - the event core library (ev and event layer) compiles and works both as
+     C and C++.
+
+   - a simple C++ wrapper that supports methods as callbacks exists.
+
+   - a full featured and widely used perl module is available.
+
+   whats missing?
+
+   - no event-like priority support at the moment (the ev priorities work
+     differently, but you can use idle watchers to get a similar effect).
+
+AUTHOR
+
+   libev was written and designed by Marc Lehmann and Emanuele Giaquinta.
+
+   The following people sent in patches or made other noteworthy
+   contributions to the design (if I forgot to include you, please shout
+   at me, it was an accident):
+
+   W.C.A. Wijngaards
+   Christopher Layne
+   Chris Brody