Example: make sure we haven't accidentally been linked against the wrong +version:

The flags argument can be used to specify special behaviour or specific -backends to use, and is usually specified as 0 (or EVFLAG_AUTO).

ev_<type>_start (loop, watch corresponding stop function (ev_<type>_stop (loop, watcher *).

As long as your watcher is active (has been started but not stopped) you must not touch the values stored in it. Most specifically you must never -reinitialise it or call its set macro.

You can check whether an event is active by calling the ev_is_active -(watcher *) macro. To see whether an event is outstanding (but the -callback for it has not been called yet) you can use the ev_is_pending -(watcher *) macro.

+reinitialise it or call its set macro.

Each and every callback receives the event loop pointer as first, the registered watcher structure as second, and a bitset of received events as third argument.

@@ -489,6 +613,84 @@ programs, though, so beware.

+ +

SUMMARY OF GENERIC WATCHER FUNCTIONS

In the following description, TYPE stands for the watcher type, +e.g. timer for ev_timer watchers and io for ev_io watchers.

ev_init (ev_TYPE *watcher, callback)

This macro initialises the generic portion of a watcher. The contents +of the watcher object can be arbitrary (so malloc will do). Only +the generic parts of the watcher are initialised, you need to call +the type-specific ev_TYPE_set macro afterwards to initialise the +type-specific parts. For each type there is also a ev_TYPE_init macro +which rolls both calls into one.

You can reinitialise a watcher at any time as long as it has been stopped +(or never started) and there are no pending events outstanding.

The callbakc is always of type void (*)(ev_loop *loop, ev_TYPE *watcher, +int revents).

ev_TYPE_set (ev_TYPE *, [args])

This macro initialises the type-specific parts of a watcher. You need to +call ev_init at least once before you call this macro, but you can +call ev_TYPE_set any number of times. You must not, however, call this +macro on a watcher that is active (it can be pending, however, which is a +difference to the ev_init macro).

Although some watcher types do not have type-specific arguments +(e.g. ev_prepare) you still need to call its set macro.

ev_TYPE_init (ev_TYPE *watcher, callback, [args])

This convinience macro rolls both ev_init and ev_TYPE_set macro +calls into a single call. This is the most convinient method to initialise +a watcher. The same limitations apply, of course.

ev_TYPE_start (loop *, ev_TYPE *watcher)

Starts (activates) the given watcher. Only active watchers will receive +events. If the watcher is already active nothing will happen.

ev_TYPE_stop (loop *, ev_TYPE *watcher)

Stops the given watcher again (if active) and clears the pending +status. It is possible that stopped watchers are pending (for example, +non-repeating timers are being stopped when they become pending), but +ev_TYPE_stop ensures that the watcher is neither active nor pending. If +you want to free or reuse the memory used by the watcher it is therefore a +good idea to always call its ev_TYPE_stop function.

bool ev_is_active (ev_TYPE *watcher)

Returns a true value iff the watcher is active (i.e. it has been started +and not yet been stopped). As long as a watcher is active you must not modify +it.

bool ev_is_pending (ev_TYPE *watcher)

Returns a true value iff the watcher is pending, (i.e. it has outstanding +events but its callback has not yet been invoked). As long as a watcher +is pending (but not active) you must not call an init function on it (but +ev_TYPE_set is safe) and you must make sure the watcher is available to +libev (e.g. you cnanot free () it).

callback = ev_cb (ev_TYPE *watcher)

Returns the callback currently set on the watcher.

ev_cb_set (ev_TYPE *watcher, callback)

Change the callback. You can change the callback at virtually any time +(modulo threads).

+ + + + +

ASSOCIATING CUSTOM DATA WITH A WATCHER

@@ -529,6 +731,10 @@ have been omitted....

This section describes each watcher in detail, but will not repeat information given in the last section.

+ + + +

`ev_io` - is this file descriptor readable or writable

@@ -568,6 +774,27 @@ typical ways of handling events, so its a good idea to use non-blocking I/O unconditionally.

Example: call stdin_readable_cb when STDIN_FILENO has become, well +readable, but only once. Since it is likely line-buffered, you could +attempt to read a whole line in the callback:

  static void
+  stdin_readable_cb (struct ev_loop *loop, struct ev_io *w, int revents)
+  {
+     ev_io_stop (loop, w);
+    .. read from stdin here (or from w->fd) and haqndle any I/O errors
+  }
+
+  ...
+  struct ev_loop *loop = ev_default_init (0);
+  struct ev_io stdin_readable;
+  ev_io_init (&stdin_readable, stdin_readable_cb, STDIN_FILENO, EV_READ);
+  ev_io_start (loop, &stdin_readable);
+  ev_loop (loop, 0);
+
+
+
+
+

`ev_timer` - relative and optionally recurring timeouts

@@ -621,6 +848,39 @@ state where you do not expect data to travel on the socket, you can stop the timer, and again will automatically restart it if need be.

Example: create a timer that fires after 60 seconds.

  static void
+  one_minute_cb (struct ev_loop *loop, struct ev_timer *w, int revents)
+  {
+    .. one minute over, w is actually stopped right here
+  }
+
+  struct ev_timer mytimer;
+  ev_timer_init (&mytimer, one_minute_cb, 60., 0.);
+  ev_timer_start (loop, &mytimer);
+
+

Example: create a timeout timer that times out after 10 seconds of +inactivity.

  static void
+  timeout_cb (struct ev_loop *loop, struct ev_timer *w, int revents)
+  {
+    .. ten seconds without any activity
+  }
+
+  struct ev_timer mytimer;
+  ev_timer_init (&mytimer, timeout_cb, 0., 10.); /* note, only repeat used */
+  ev_timer_again (&mytimer); /* start timer */
+  ev_loop (loop, 0);
+
+  // and in some piece of code that gets executed on any "activity":
+  // reset the timeout to start ticking again at 10 seconds
+  ev_timer_again (&mytimer);
+
+
+
+
+

`ev_periodic` - to cron or not to cron

@@ -630,8 +890,8 @@ the timer, and again will automatically restart it if need be.

Unlike ev_timer's, they are not based on real time (or relative time) but on wallclock time (absolute time). You can tell a periodic watcher to trigger "at" some specific point in time. For example, if you tell a -periodic watcher to trigger in 10 seconds (by specifiying e.g. c<ev_now () -+ 10.>) and then reset your system clock to the last year, then it will +periodic watcher to trigger in 10 seconds (by specifiying e.g. ev_now () ++ 10.) and then reset your system clock to the last year, then it will take a year to trigger the event (unlike an ev_timer, which would trigger roughly 10 seconds later and of course not if you reset your system time again).

@@ -714,6 +974,42 @@ a different time than the last time it was called (e.g. in a crond like program when the crontabs have changed).

Example: call a callback every hour, or, more precisely, whenever the +system clock is divisible by 3600. The callback invocation times have +potentially a lot of jittering, but good long-term stability.

  static void
+  clock_cb (struct ev_loop *loop, struct ev_io *w, int revents)
+  {
+    ... its now a full hour (UTC, or TAI or whatever your clock follows)
+  }
+
+  struct ev_periodic hourly_tick;
+  ev_periodic_init (&hourly_tick, clock_cb, 0., 3600., 0);
+  ev_periodic_start (loop, &hourly_tick);
+
+

Example: the same as above, but use a reschedule callback to do it:

  #include <math.h>
+
+  static ev_tstamp
+  my_scheduler_cb (struct ev_periodic *w, ev_tstamp now)
+  {
+    return fmod (now, 3600.) + 3600.;
+  }
+
+  ev_periodic_init (&hourly_tick, clock_cb, 0., 0., my_scheduler_cb);
+
+

Example: call a callback every hour, starting now:

  struct ev_periodic hourly_tick;
+  ev_periodic_init (&hourly_tick, clock_cb,
+                    fmod (ev_now (loop), 3600.), 3600., 0);
+  ev_periodic_start (loop, &hourly_tick);
+
+
+
+
+

`ev_signal` - signal me when a signal gets signalled

@@ -737,6 +1033,10 @@ of the SIGxxx constants).

+ + + +

`ev_child` - wait for pid status changes

@@ -754,6 +1054,21 @@ the status word (use the macros from sys/wait.h and see your system process causing the status change.

Example: try to exit cleanly on SIGINT and SIGTERM.

  static void
+  sigint_cb (struct ev_loop *loop, struct ev_signal *w, int revents)
+  {
+    ev_unloop (loop, EVUNLOOP_ALL);
+  }
+
+  struct ev_signal signal_watcher;
+  ev_signal_init (&signal_watcher, sigint_cb, SIGINT);
+  ev_signal_start (loop, &sigint_cb);
+
+
+
+
+

`ev_idle` - when you've got nothing better to do

@@ -779,6 +1094,24 @@ kind. There is a ev_idle_set macro, but using it is utterly pointle believe me.

Example: dynamically allocate an ev_idle, start it, and in the +callback, free it. Alos, use no error checking, as usual.

  static void
+  idle_cb (struct ev_loop *loop, struct ev_idle *w, int revents)
+  {
+    free (w);
+    // now do something you wanted to do when the program has
+    // no longer asnything immediate to do.
+  }
+
+  struct ev_idle *idle_watcher = malloc (sizeof (struct ev_idle));
+  ev_idle_init (idle_watcher, idle_cb);
+  ev_idle_start (loop, idle_cb);
+
+
+
+
+

`ev_prepare` and `ev_check` - customise your event loop

@@ -786,9 +1119,10 @@ believe me.

Prepare and check watchers are usually (but not always) used in tandem: prepare watchers get invoked before the process blocks and check watchers afterwards.

Their main purpose is to integrate other event mechanisms into libev. This -could be used, for example, to track variable changes, implement your own -watchers, integrate net-snmp or a coroutine library and lots more.

Their main purpose is to integrate other event mechanisms into libev and +their use is somewhat advanced. This could be used, for example, to track +variable changes, implement your own watchers, integrate net-snmp or a +coroutine library and lots more.

This is done by examining in each prepare call which file descriptors need to be watched by the other library, registering ev_io watchers for them and starting an ev_timer watcher for any timeouts (many libraries @@ -814,6 +1148,96 @@ parameters of any kind. There are ev_prepare_set and ev_check macros, but using them is utterly, utterly and completely pointless.


 	
 
+Example: *TODO*.
+
+
+
+
+
+
+ev_embed - when one backend isn't enough
+
+This is a rather advanced watcher type that lets you embed one event loop
+into another (currently only ev_io events are supported in the embedded
+loop, other types of watchers might be handled in a delayed or incorrect
+fashion and must not be used).
+There are primarily two reasons you would want that: work around bugs and
+prioritise I/O.
+As an example for a bug workaround, the kqueue backend might only support
+sockets on some platform, so it is unusable as generic backend, but you
+still want to make use of it because you have many sockets and it scales
+so nicely. In this case, you would create a kqueue-based loop and embed it
+into your default loop (which might use e.g. poll). Overall operation will
+be a bit slower because first libev has to poll and then call kevent, but
+at least you can use both at what they are best.
+As for prioritising I/O: rarely you have the case where some fds have
+to be watched and handled very quickly (with low latency), and even
+priorities and idle watchers might have too much overhead. In this case
+you would put all the high priority stuff in one loop and all the rest in
+a second one, and embed the second one in the first.
+As long as the watcher is active, the callback will be invoked every time
+there might be events pending in the embedded loop. The callback must then
+call ev_embed_sweep (mainloop, watcher) to make a single sweep and invoke
+their callbacks (you could also start an idle watcher to give the embedded
+loop strictly lower priority for example). You can also set the callback
+to 0, in which case the embed watcher will automatically execute the
+embedded loop sweep.
+As long as the watcher is started it will automatically handle events. The
+callback will be invoked whenever some events have been handled. You can
+set the callback to 0 to avoid having to specify one if you are not
+interested in that.
+Also, there have not currently been made special provisions for forking:
+when you fork, you not only have to call ev_loop_fork on both loops,
+but you will also have to stop and restart any ev_embed watchers
+yourself.
+Unfortunately, not all backends are embeddable, only the ones returned by
+ev_embeddable_backends are, which, unfortunately, does not include any
+portable one.
+So when you want to use this feature you will always have to be prepared
+that you cannot get an embeddable loop. The recommended way to get around
+this is to have a separate variables for your embeddable loop, try to
+create it, and if that fails, use the normal loop for everything:
+  struct ev_loop *loop_hi = ev_default_init (0);
+  struct ev_loop *loop_lo = 0;
+  struct ev_embed embed;
+
+  // see if there is a chance of getting one that works
+  // (remember that a flags value of 0 means autodetection)
+  loop_lo = ev_embeddable_backends () & ev_recommended_backends ()
+    ? ev_loop_new (ev_embeddable_backends () & ev_recommended_backends ())
+    : 0;
+
+  // if we got one, then embed it, otherwise default to loop_hi
+  if (loop_lo)
+    {
+      ev_embed_init (&embed, 0, loop_lo);
+      ev_embed_start (loop_hi, &embed);
+    }
+  else
+    loop_lo = loop_hi;
+
+
+
+	ev_embed_init (ev_embed *, callback, struct ev_loop *embedded_loop)
+	ev_embed_set (ev_embed *, callback, struct ev_loop *embedded_loop)
+	
+		Configures the watcher to embed the given loop, which must be
+embeddable. If the callback is 0, then ev_embed_sweep will be
+invoked automatically, otherwise it is the responsibility of the callback
+to invoke it (it will continue to be called until the sweep has been done,
+if you do not want thta, you need to temporarily stop the embed watcher).
+	
+	ev_embed_sweep (loop, ev_embed *)
+	
+		Make a single, non-blocking sweep over the embedded loop. This works
+similarly to ev_loop (embedded_loop, EVLOOP_NONBLOCK), but in the most
+apropriate way for embedded loops.
+	
+
+
+
+
+
 
 
 OTHER FUNCTIONS
Top
@@ -850,23 +1274,28 @@ value passed to ev_once:
 
 
 	
-	ev_feed_event (loop, watcher, int events)
+	ev_feed_event (ev_loop *, watcher *, int revents)
 	
 		Feeds the given event set into the event loop, as if the specified event
 had happened for the specified watcher (which must be a pointer to an
 initialised but not necessarily started event watcher).
 	
-	ev_feed_fd_event (loop, int fd, int revents)
+	ev_feed_fd_event (ev_loop *, int fd, int revents)
 	
 		Feed an event on the given fd, as if a file descriptor backend detected
 the given events it.
 	
-	ev_feed_signal_event (loop, int signum)
+	ev_feed_signal_event (ev_loop *loop, int signum)
 	
-		Feed an event as if the given signal occured (loop must be the default loop!).
+		Feed an event as if the given signal occured (loop must be the default
+loop!).
 	
 
 
+
+
+
+
 
 LIBEVENT EMULATION
Top
 
@@ -890,12 +1319,384 @@ to use the libev header file and library.
 
 C++ SUPPORT
Top
 
-TBD.
+Libev comes with some simplistic wrapper classes for C++ that mainly allow
+you to use some convinience methods to start/stop watchers and also change
+the callback model to a model using method callbacks on objects.
+To use it,
+  #include <ev++.h>
+
+
+(it is not installed by default). This automatically includes ev.h
+and puts all of its definitions (many of them macros) into the global
+namespace. All C++ specific things are put into the ev namespace.
+It should support all the same embedding options as ev.h, most notably
+EV_MULTIPLICITY.
+Here is a list of things available in the ev namespace:
+
+	ev::READ, ev::WRITE etc.
+	
+		These are just enum values with the same values as the EV_READ etc.
+macros from ev.h.
+	
+	ev::tstamp, ev::now
+	
+		Aliases to the same types/functions as with the ev_ prefix.
+	
+	ev::io, ev::timer, ev::periodic, ev::idle, ev::sig etc.
+	
+		For each ev_TYPE watcher in ev.h there is a corresponding class of
+the same name in the ev namespace, with the exception of ev_signal
+which is called ev::sig to avoid clashes with the signal macro
+defines by many implementations.
+		All of those classes have these methods:
+		
+			

+				ev::TYPE::TYPE (object *, object::method *)
+				ev::TYPE::TYPE (object *, object::method *, struct ev_loop *)
+				ev::TYPE::~TYPE
+				
+					The constructor takes a pointer to an object and a method pointer to
+the event handler callback to call in this class. The constructor calls
+ev_init for you, which means you have to call the set method
+before starting it. If you do not specify a loop then the constructor
+automatically associates the default loop with this watcher.
+					The destructor automatically stops the watcher if it is active.
+				
+				w->set (struct ev_loop *)
+				
+					Associates a different struct ev_loop with this watcher. You can only
+do this when the watcher is inactive (and not pending either).
+				
+				w->set ([args])
+				
+					Basically the same as ev_TYPE_set, with the same args. Must be
+called at least once.  Unlike the C counterpart, an active watcher gets
+automatically stopped and restarted.
+				
+				w->start ()
+				
+					Starts the watcher. Note that there is no loop argument as the
+constructor already takes the loop.
+				
+				w->stop ()
+				
+					Stops the watcher if it is active. Again, no loop argument.
+				
+				w->again ()       ev::timer, ev::periodic only
+				
+					For ev::timer and ev::periodic, this invokes the corresponding
+ev_TYPE_again function.
+				
+				w->sweep ()       ev::embed only
+				
+					Invokes ev_embed_sweep.
+				
+			
+		
+	
+
+Example: Define a class with an IO and idle watcher, start one of them in
+the constructor.
+  class myclass
+  {
+    ev_io   io;   void io_cb   (ev::io   &w, int revents);
+    ev_idle idle  void idle_cb (ev::idle &w, int revents);
+
+    myclass ();
+  }
+
+  myclass::myclass (int fd)
+  : io   (this, &myclass::io_cb),
+    idle (this, &myclass::idle_cb)
+  {
+    io.start (fd, ev::READ);
+  }
+
+
+
+
+EMBEDDING
Top
+
+Libev can (and often is) directly embedded into host
+applications. Examples of applications that embed it include the Deliantra
+Game Server, the EV perl module, the GNU Virtual Private Ethernet (gvpe)
+and rxvt-unicode.
+The goal is to enable you to just copy the neecssary files into your
+source directory without having to change even a single line in them, so
+you can easily upgrade by simply copying (or having a checked-out copy of
+libev somewhere in your source tree).
+
+
+FILESETS
+
+Depending on what features you need you need to include one or more sets of files
+in your app.
+
+
+CORE EVENT LOOP
+
+To include only the libev core (all the ev_* functions), with manual
+configuration (no autoconf):
+  #define EV_STANDALONE 1
+  #include "ev.c"
+
+
+This will automatically include ev.h, too, and should be done in a
+single C source file only to provide the function implementations. To use
+it, do the same for ev.h in all files wishing to use this API (best
+done by writing a wrapper around ev.h that you can include instead and
+where you can put other configuration options):
+  #define EV_STANDALONE 1
+  #include "ev.h"
+
+
+Both header files and implementation files can be compiled with a C++
+compiler (at least, thats a stated goal, and breakage will be treated
+as a bug).
+You need the following files in your source tree, or in a directory
+in your include path (e.g. in libev/ when using -Ilibev):
+  ev.h
+  ev.c
+  ev_vars.h
+  ev_wrap.h
+
+  ev_win32.c      required on win32 platforms only
+
+  ev_select.c     only when select backend is enabled (which is is by default)
+  ev_poll.c       only when poll backend is enabled (disabled by default)
+  ev_epoll.c      only when the epoll backend is enabled (disabled by default)
+  ev_kqueue.c     only when the kqueue backend is enabled (disabled by default)
+  ev_port.c       only when the solaris port backend is enabled (disabled by default)
+
+
+ev.c includes the backend files directly when enabled, so you only need
+to compile a single file.
+
+
+LIBEVENT COMPATIBILITY API
+
+To include the libevent compatibility API, also include:
+  #include "event.c"
+
+
+in the file including ev.c, and:
+  #include "event.h"
+
+
+in the files that want to use the libevent API. This also includes ev.h.
+You need the following additional files for this:
+  event.h
+  event.c
+
+
+
+
+AUTOCONF SUPPORT
+
+Instead of using EV_STANDALONE=1 and providing your config in
+whatever way you want, you can also m4_include([libev.m4]) in your
+configure.ac and leave EV_STANDALONE off. ev.c will then include
+config.h and configure itself accordingly.
+For this of course you need the m4 file:
+  libev.m4
+
+
+
+
+PREPROCESSOR SYMBOLS/MACROS
+
+Libev can be configured via a variety of preprocessor symbols you have to define
+before including any of its files. The default is not to build for multiplicity
+and only include the select backend.
+
+	EV_STANDALONE
+	
+		Must always be 1 if you do not use autoconf configuration, which
+keeps libev from including config.h, and it also defines dummy
+implementations for some libevent functions (such as logging, which is not
+supported). It will also not define any of the structs usually found in
+event.h that are not directly supported by the libev core alone.
+	
+	EV_USE_MONOTONIC
+	
+		If defined to be 1, libev will try to detect the availability of the
+monotonic clock option at both compiletime and runtime. Otherwise no use
+of the monotonic clock option will be attempted. If you enable this, you
+usually have to link against librt or something similar. Enabling it when
+the functionality isn't available is safe, though, althoguh you have
+to make sure you link against any libraries where the clock_gettime
+function is hiding in (often -lrt).
+	
+	EV_USE_REALTIME
+	
+		If defined to be 1, libev will try to detect the availability of the
+realtime clock option at compiletime (and assume its availability at
+runtime if successful). Otherwise no use of the realtime clock option will
+be attempted. This effectively replaces gettimeofday by clock_get
+(CLOCK_REALTIME, ...) and will not normally affect correctness. See tzhe note about libraries
+in the description of EV_USE_MONOTONIC, though.
+	
+	EV_USE_SELECT
+	
+		If undefined or defined to be 1, libev will compile in support for the
+select(2) backend. No attempt at autodetection will be done: if no
+other method takes over, select will be it. Otherwise the select backend
+will not be compiled in.
+	
+	EV_SELECT_USE_FD_SET
+	
+		If defined to 1, then the select backend will use the system fd_set
+structure. This is useful if libev doesn't compile due to a missing
+NFDBITS or fd_mask definition or it misguesses the bitset layout on
+exotic systems. This usually limits the range of file descriptors to some
+low limit such as 1024 or might have other limitations (winsocket only
+allows 64 sockets). The FD_SETSIZE macro, set before compilation, might
+influence the size of the fd_set used.
+	
+	EV_SELECT_IS_WINSOCKET
+	
+		When defined to 1, the select backend will assume that
+select/socket/connect etc. don't understand file descriptors but
+wants osf handles on win32 (this is the case when the select to
+be used is the winsock select). This means that it will call
+_get_osfhandle on the fd to convert it to an OS handle. Otherwise,
+it is assumed that all these functions actually work on fds, even
+on win32. Should not be defined on non-win32 platforms.
+	
+	EV_USE_POLL
+	
+		If defined to be 1, libev will compile in support for the poll(2)
+backend. Otherwise it will be enabled on non-win32 platforms. It
+takes precedence over select.
+	
+	EV_USE_EPOLL
+	
+		If defined to be 1, libev will compile in support for the Linux
+epoll(7) backend. Its availability will be detected at runtime,
+otherwise another method will be used as fallback. This is the
+preferred backend for GNU/Linux systems.
+	
+	EV_USE_KQUEUE
+	
+		If defined to be 1, libev will compile in support for the BSD style
+kqueue(2) backend. Its actual availability will be detected at runtime,
+otherwise another method will be used as fallback. This is the preferred
+backend for BSD and BSD-like systems, although on most BSDs kqueue only
+supports some types of fds correctly (the only platform we found that
+supports ptys for example was NetBSD), so kqueue might be compiled in, but
+not be used unless explicitly requested. The best way to use it is to find
+out wether kqueue supports your type of fd properly and use an embedded
+kqueue loop.
+	
+	EV_USE_PORT
+	
+		If defined to be 1, libev will compile in support for the Solaris
+10 port style backend. Its availability will be detected at runtime,
+otherwise another method will be used as fallback. This is the preferred
+backend for Solaris 10 systems.
+	
+	EV_USE_DEVPOLL
+	
+		reserved for future expansion, works like the USE symbols above.
+	
+	EV_H
+	
+		The name of the ev.h header file used to include it. The default if
+undefined is <ev.h> in event.h and "ev.h" in ev.c. This
+can be used to virtually rename the ev.h header file in case of conflicts.
+	
+	EV_CONFIG_H
+	
+		If EV_STANDALONE isn't 1, this variable can be used to override
+ev.c's idea of where to find the config.h file, similarly to
+EV_H, above.
+	
+	EV_EVENT_H
+	
+		Similarly to EV_H, this macro can be used to override event.c's idea
+of how the event.h header can be found.
+	
+	EV_PROTOTYPES
+	
+		If defined to be 0, then ev.h will not define any function
+prototypes, but still define all the structs and other symbols. This is
+occasionally useful if you want to provide your own wrapper functions
+around libev functions.
+	
+	EV_MULTIPLICITY
+	
+		If undefined or defined to 1, then all event-loop-specific functions
+will have the struct ev_loop * as first argument, and you can create
+additional independent event loops. Otherwise there will be no support
+for multiple event loops and there is no first event loop pointer
+argument. Instead, all functions act on the single default loop.
+	
+	EV_PERIODICS
+	
+		If undefined or defined to be 1, then periodic timers are supported,
+otherwise not. This saves a few kb of code.
+	
+	EV_COMMON
+	
+		By default, all watchers have a void *data member. By redefining
+this macro to a something else you can include more and other types of
+members. You have to define it each time you include one of the files,
+though, and it must be identical each time.
+		For example, the perl EV module uses something like this:
+  #define EV_COMMON                       \
+    SV *self; /* contains this struct */  \
+    SV *cb_sv, *fh /* note no trailing ";" */
+
+
+	
+	EV_CB_DECLARE(type)
+	EV_CB_INVOKE(watcher,revents)
+	ev_set_cb(ev,cb)
+	
+		Can be used to change the callback member declaration in each watcher,
+and the way callbacks are invoked and set. Must expand to a struct member
+definition and a statement, respectively. See the ev.v header file for
+their default definitions. One possible use for overriding these is to
+avoid the ev_loop pointer as first argument in all cases, or to use method
+calls instead of plain function calls in C++.
+
+
+EXAMPLES
+
+		For a real-world example of a program the includes libev
+verbatim, you can have a look at the EV perl module
+(http://software.schmorp.de/pkg/EV.html). It has the libev files in
+the libev/ subdirectory and includes them in the EV/EVAPI.h (public
+interface) and EV.xs (implementation) files. Only the EV.xs file
+will be compiled. It is pretty complex because it provides its own header
+file.
+		The usage in rxvt-unicode is simpler. It has a ev_cpp.h header file
+that everybody includes and which overrides some autoconf choices:
+   #define EV_USE_POLL 0
+   #define EV_MULTIPLICITY 0
+   #define EV_PERIODICS 0
+   #define EV_CONFIG_H <config.h>
+
+   #include "ev++.h"
+
+
+		And a ev_cpp.C implementation file that contains libev proper and is compiled:
+   #include "rxvttoolkit.h"
+
+   /* darwin has problems with its header files in C++, requiring this namespace juggling */
+   using namespace ev;
+
+   #include "ev.c"
+
+
+
+
+
 
 
 AUTHOR
Top
 
-Marc Lehmann <libev@schmorp.de>.
+		Marc Lehmann <libev@schmorp.de>.

GLOBAL FUNCTIONS

SUMMARY OF GENERIC WATCHER FUNCTIONS

ASSOCIATING CUSTOM DATA WITH A WATCHER

`ev_io` - is this file descriptor readable or writable

`ev_timer` - relative and optionally recurring timeouts

`ev_periodic` - to cron or not to cron

`ev_signal` - signal me when a signal gets signalled

`ev_child` - wait for pid status changes

`ev_idle` - when you've got nothing better to do

`ev_prepare` and `ev_check` - customise your event loop

`ev_embed` - when one backend isn't enough

OTHER FUNCTIONS

LIBEVENT EMULATION

C++ SUPPORT

EMBEDDING

FILESETS

CORE EVENT LOOP

LIBEVENT COMPATIBILITY API

AUTOCONF SUPPORT

PREPROCESSOR SYMBOLS/MACROS

EXAMPLES

AUTHOR

GLOBAL FUNCTIONS

SUMMARY OF GENERIC WATCHER FUNCTIONS

ASSOCIATING CUSTOM DATA WITH A WATCHER

ev_io - is this file descriptor readable or writable

ev_timer - relative and optionally recurring timeouts

ev_periodic - to cron or not to cron

ev_signal - signal me when a signal gets signalled

ev_child - wait for pid status changes

ev_idle - when you've got nothing better to do

ev_prepare and ev_check - customise your event loop

ev_embed - when one backend isn't enough

OTHER FUNCTIONS

LIBEVENT EMULATION

C++ SUPPORT

EMBEDDING

FILESETS

CORE EVENT LOOP

LIBEVENT COMPATIBILITY API

AUTOCONF SUPPORT

PREPROCESSOR SYMBOLS/MACROS

EXAMPLES

AUTHOR

`ev_io` - is this file descriptor readable or writable

`ev_timer` - relative and optionally recurring timeouts

`ev_periodic` - to cron or not to cron

`ev_signal` - signal me when a signal gets signalled

`ev_child` - wait for pid status changes

`ev_idle` - when you've got nothing better to do

`ev_prepare` and `ev_check` - customise your event loop

`ev_embed` - when one backend isn't enough