better

1 files changed, 39 insertions, 111 deletions

diff --git a/README b/README
index c614ed4..ca403c6 100644
--- a/README
+++ b/README
@@ -1,128 +1,56 @@
 libev is a high-performance event loop/event model with lots of features.
 (see benchmark at http://libev.schmorp.de/bench.html)
 
-   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
-
-   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.
 
-ABOUT THIS DISTRIBUTION
+ABOUT
 
-   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.
-
-   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.
+   Homepage: http://software.schmorp.de/pkg/libev
+   Mailinglist: libev@lists.schmorp.de
+                http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
+   Library Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod
 
-   If you are looking for an easily embeddable version, I recommend using
-   the libev standalone distribution or the CVS repository.
+   Libev is modelled (very losely) after libevent and the Event perl
+   module, but is faster, scales better and is more correct, and also more
+   featureful. And also smaller. Yay.
+
+   Some of the specialties of libev not commonly found elsewhere are:
+   
+   - extensive and detailed, readable documentation (not doxygen garbage).
+   - fully supports fork, can detect fork in various ways and automatically
+     re-arms kernel mechanisms that do not support fork.
+   - highly optimised select, poll, epoll, kqueue and event ports backends.
+   - filesystem object (path) watching (with optional linux inotify support).
+   - wallclock-based times (using absolute time, cron-like).
+   - relative timers/timeouts (handle time jumps).
+   - fast intra-thread communication between multiple
+     event loops (with optional fast linux eventfd backend).
+   - extremely easy to embed.
+   - very small codebase, no bloated library.
+   - fully extensible by being able to plug into the event loop,
+     integrate other event loops, integrate other event loop users.
+   - very little memory use (small watchers, small event loop data).
+   - optional C++ interface allowing method and function callbacks
+     at no extra memory or runtime overhead.
+   - optional Perl interface with similar characteristics (capable
+     of running Glib/Gtk2 on libev, interfaces with Net::SNMP and
+     libadns).
+   - support for other languages (multiple C++ interfaces, D, Ruby,
+     Python) available from third-parties.
 
    Examples of programs that embed libev: the EV perl module,
-   rxvt-unicode, gvpe (GNU Virtual Private Ethernet) and deliantra
-   (http://www.deliantra.net).
-
-DIFFERENCES AND COMPARISON TO LIBEVENT
-
-   The comparisons below are relative to libevent-1.3e.
-
-   - 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).
-
-   - fork() is supported and can be handled
-     (there is no way to recover from a fork with libevent).
-
-   - timers are handled as a priority queue (important operations are O(1))
-     (libevent uses a much less efficient but more complex red-black tree).
-
-   - 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.
-
-   - timers can be repeating (both absolute and relative ones).
-
-   - absolute timers can have customised rescheduling hooks (suitable for cron-like
-     applications).
-
-   - detects time jumps and adjusts timers
-     (works for both forward and backward time jumps and also for absolute timers).
-
-   - race-free signal processing
-     (libevent may delay processing signals till after the next event).
-
-   - more efficient epoll backend
-     (stopping and starting an io watcher between two loop iterations will not
-     result in spurious epoll_ctl calls).
-
-   - usually less calls to gettimeofday and clock_gettime
-     (libevent calls it on every timer event change, libev twice per iteration).
-
-   - watchers use less memory
-     (libevent watcher on amd64: 152 bytes, libev native: <= 56 bytes, libevent emulation: 144 bytes).
-
-   - library uses less memory
-     (libevent allocates large data structures wether used or not, libev
-     scales all its data structures dynamically).
-
-   - 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?
+   rxvt-unicode, gvpe (GNU Virtual Private Ethernet), the Deliantra MMORPG
+   server (http://www.deliantra.net/), Rubinius (a next-generation Ruby
+   VM), the Ebb web server, the Rev event toolkit.
 
-   - 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
+CONTRIBUTORS
 
    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):
+   contributions to the design (for minor patches, see the Changes
+   file. If I forgot to include you, please shout at me, it was an
+   accident):
 
    W.C.A. Wijngaards
    Christopher Layne