--- libev/ev.pod	2010/10/22 09:34:01	1.316
+++ libev/ev.pod	2010/11/03 20:03:21	1.340
@@ -45,7 +45,7 @@
    main (void)
    {
      // use the default event loop unless you have special needs
-     struct ev_loop *loop = ev_default_loop (0);
+     struct ev_loop *loop = EV_DEFAULT;
 
      // initialise an io watcher, then start it
      // this one will watch for stdin to become readable
@@ -80,6 +80,14 @@
 Familiarity with event based programming techniques in general is assumed
 throughout this document.
 
+=head1 WHAT TO READ WHEN IN A HURRY
+
+This manual tries to be very detailed, but unfortunately, this also makes
+it very long. If you just want to know the basics of libev, I suggest
+reading L<ANATOMY OF A WATCHER>, then the L<EXAMPLE PROGRAM> above and
+look up the missing functions in L<GLOBAL FUNCTIONS> and the C<ev_io> and
+C<ev_timer> sections in L<WATCHER TYPES>.
+
 =head1 ABOUT LIBEV
 
 Libev is an event loop: you register interest in certain events (such as a
@@ -126,7 +134,7 @@
 =head2 TIME REPRESENTATION
 
 Libev represents time as a single floating point number, representing
-the (fractional) number of seconds since the (POSIX) epoch (in practise
+the (fractional) number of seconds since the (POSIX) epoch (in practice
 somewhere near the beginning of 1970, details are complicated, don't
 ask). This type is called C<ev_tstamp>, which is what you should use
 too. It usually aliases to the C<double> type in C. When you need to do
@@ -167,7 +175,8 @@
 
 Returns the current time as libev would use it. Please note that the
 C<ev_now> function is usually faster and also often returns the timestamp
-you actually want to know.
+you actually want to know. Also interesting is the combination of
+C<ev_update_now> and C<ev_now>.
 
 =item ev_sleep (ev_tstamp interval)
 
@@ -194,7 +203,8 @@
 not a problem.
 
 Example: Make sure we haven't accidentally been linked against the wrong
-version (note, however, that this will not detect ABI mismatches :).
+version (note, however, that this will not detect other ABI mismatches,
+such as LFS or reentrancy).
 
    assert (("libev version mismatch",
             ev_version_major () == EV_VERSION_MAJOR
@@ -215,24 +225,25 @@
 
 =item unsigned int ev_recommended_backends ()
 
-Return the set of all backends compiled into this binary of libev and also
-recommended for this platform. This set is often smaller than the one
-returned by C<ev_supported_backends>, as for example kqueue is broken on
-most BSDs and will not be auto-detected unless you explicitly request it
-(assuming you know what you are doing). This is the set of backends that
-libev will probe for if you specify no backends explicitly.
+Return the set of all backends compiled into this binary of libev and
+also recommended for this platform, meaning it will work for most file
+descriptor types. This set is often smaller than the one returned by
+C<ev_supported_backends>, as for example kqueue is broken on most BSDs
+and will not be auto-detected unless you explicitly request it (assuming
+you know what you are doing). This is the set of backends that libev will
+probe for if you specify no backends explicitly.
 
 =item unsigned int ev_embeddable_backends ()
 
 Returns the set of backends that are embeddable in other event loops. This
-is the theoretical, all-platform, value. To find which backends
-might be supported on the current system, you would need to look at
-C<ev_embeddable_backends () & ev_supported_backends ()>, likewise for
-recommended ones.
+value is platform-specific but can include backends not available on the
+current system. To find which embeddable backends might be supported on
+the current system, you would need to look at C<ev_embeddable_backends ()
+& ev_supported_backends ()>, likewise for recommended ones.
 
 See the description of C<ev_embed> watchers for more info.
 
-=item ev_set_allocator (void *(*cb)(void *ptr, long size)) [NOT REENTRANT]
+=item ev_set_allocator (void *(*cb)(void *ptr, long size))
 
 Sets the allocation function to use (the prototype is similar - the
 semantics are identical to the C<realloc> C89/SuS/POSIX function). It is
@@ -268,7 +279,7 @@
    ...
    ev_set_allocator (persistent_realloc);
 
-=item ev_set_syserr_cb (void (*cb)(const char *msg)); [NOT REENTRANT]
+=item ev_set_syserr_cb (void (*cb)(const char *msg))
 
 Set the callback function to call on a retryable system call error (such
 as failed select, poll, epoll_wait). The message is a printable string
@@ -292,38 +303,63 @@
 
 =back
 
-=head1 FUNCTIONS CONTROLLING THE EVENT LOOP
+=head1 FUNCTIONS CONTROLLING EVENT LOOPS
 
 An event loop is described by a C<struct ev_loop *> (the C<struct> is
 I<not> optional in this case unless libev 3 compatibility is disabled, as
 libev 3 had an C<ev_loop> function colliding with the struct name).
 
 The library knows two types of such loops, the I<default> loop, which
-supports signals and child events, and dynamically created event loops
-which do not.
+supports child process events, and dynamically created event loops which
+do not.
 
 =over 4
 
 =item struct ev_loop *ev_default_loop (unsigned int flags)
 
-This will initialise the default event loop if it hasn't been initialised
-yet and return it. If the default loop could not be initialised, returns
-false. If it already was initialised it simply returns it (and ignores the
-flags. If that is troubling you, check C<ev_backend ()> afterwards).
+This returns the "default" event loop object, which is what you should
+normally use when you just need "the event loop". Event loop objects and
+the C<flags> parameter are described in more detail in the entry for
+C<ev_loop_new>.
+
+If the default loop is already initialised then this function simply
+returns it (and ignores the flags. If that is troubling you, check
+C<ev_backend ()> afterwards). Otherwise it will create it with the given
+flags, which should almost always be C<0>, unless the caller is also the
+one calling C<ev_run> or otherwise qualifies as "the main program".
 
 If you don't know what event loop to use, use the one returned from this
-function.
+function (or via the C<EV_DEFAULT> macro).
 
 Note that this function is I<not> thread-safe, so if you want to use it
-from multiple threads, you have to lock (note also that this is unlikely,
-as loops cannot be shared easily between threads anyway).
+from multiple threads, you have to employ some kind of mutex (note also
+that this case is unlikely, as loops cannot be shared easily between
+threads anyway).
+
+The default loop is the only loop that can handle C<ev_child> watchers,
+and to do this, it always registers a handler for C<SIGCHLD>. If this is
+a problem for your application you can either create a dynamic loop with
+C<ev_loop_new> which doesn't do that, or you can simply overwrite the
+C<SIGCHLD> signal handler I<after> calling C<ev_default_init>.
+
+Example: This is the most typical usage.
+
+   if (!ev_default_loop (0))
+     fatal ("could not initialise libev, bad $LIBEV_FLAGS in environment?");
+
+Example: Restrict libev to the select and poll backends, and do not allow
+environment settings to be taken into account:
+
+   ev_default_loop (EVBACKEND_POLL | EVBACKEND_SELECT | EVFLAG_NOENV);
+
+=item struct ev_loop *ev_loop_new (unsigned int flags)
 
-The default loop is the only loop that can handle C<ev_signal> and
-C<ev_child> watchers, and to do this, it always registers a handler
-for C<SIGCHLD>. If this is a problem for your application you can either
-create a dynamic loop with C<ev_loop_new> that doesn't do that, or you
-can simply overwrite the C<SIGCHLD> signal handler I<after> calling
-C<ev_default_init>.
+This will create and initialise a new event loop object. If the loop
+could not be initialised, returns false.
+
+Note that this function I<is> thread-safe, and one common way to use
+libev with threads is indeed to create one loop per thread, and using the
+default loop in the "main" or "initial" thread.
 
 The flags argument can be used to specify special behaviour or specific
 backends to use, and is usually specified as C<0> (or C<EVFLAG_AUTO>).
@@ -368,14 +404,14 @@
 =item C<EVFLAG_NOINOTIFY>
 
 When this flag is specified, then libev will not attempt to use the
-I<inotify> API for it's C<ev_stat> watchers. Apart from debugging and
+I<inotify> API for its C<ev_stat> watchers. Apart from debugging and
 testing, this flag can be useful to conserve inotify file descriptors, as
 otherwise each loop using C<ev_stat> watchers consumes one inotify handle.
 
 =item C<EVFLAG_SIGNALFD>
 
 When this flag is specified, then libev will attempt to use the
-I<signalfd> API for it's C<ev_signal> (and C<ev_child>) watchers. This API
+I<signalfd> API for its C<ev_signal> (and C<ev_child>) watchers. This API
 delivers signals synchronously, which makes it both faster and might make
 it possible to get the queued signal data. It can also simplify signal
 handling with threads, as long as you properly block signals in your
@@ -429,11 +465,13 @@
 The epoll mechanism deserves honorable mention as the most misdesigned
 of the more advanced event mechanisms: mere annoyances include silently
 dropping file descriptors, requiring a system call per change per file
-descriptor (and unnecessary guessing of parameters), problems with dup and
-so on. The biggest issue is fork races, however - if a program forks then
-I<both> parent and child process have to recreate the epoll set, which can
-take considerable time (one syscall per file descriptor) and is of course
-hard to detect.
+descriptor (and unnecessary guessing of parameters), problems with dup,
+returning before the timeout value, resulting in additional iterations
+(and only giving 5ms accuracy while select on the same platform gives
+0.1ms) and so on. The biggest issue is fork races, however - if a program
+forks then I<both> parent and child process have to recreate the epoll
+set, which can take considerable time (one syscall per file descriptor)
+and is of course hard to detect.
 
 Epoll is also notoriously buggy - embedding epoll fds I<should> work, but
 of course I<doesn't>, and epoll just loves to report events for totally
@@ -445,6 +483,8 @@
 not least, it also refuses to work with some file descriptors which work
 perfectly fine with C<select> (files, many character devices...).
 
+Epoll is truly the train wreck analog among event poll mechanisms.
+
 While stopping, setting and starting an I/O watcher in the same iteration
 will result in some caching, there is still a system call per such
 incident (because the same I<file descriptor> could point to a different
@@ -551,69 +591,47 @@
 here). If none are specified, all backends in C<ev_recommended_backends
 ()> will be tried.
 
-Example: This is the most typical usage.
-
-   if (!ev_default_loop (0))
-     fatal ("could not initialise libev, bad $LIBEV_FLAGS in environment?");
-
-Example: Restrict libev to the select and poll backends, and do not allow
-environment settings to be taken into account:
-
-   ev_default_loop (EVBACKEND_POLL | EVBACKEND_SELECT | EVFLAG_NOENV);
-
-Example: Use whatever libev has to offer, but make sure that kqueue is
-used if available (warning, breaks stuff, best use only with your own
-private event loop and only if you know the OS supports your types of
-fds):
-
-   ev_default_loop (ev_recommended_backends () | EVBACKEND_KQUEUE);
-
-=item struct ev_loop *ev_loop_new (unsigned int flags)
-
-Similar to C<ev_default_loop>, but always creates a new event loop that is
-always distinct from the default loop.
-
-Note that this function I<is> thread-safe, and one common way to use
-libev with threads is indeed to create one loop per thread, and using the
-default loop in the "main" or "initial" thread.
-
 Example: Try to create a event loop that uses epoll and nothing else.
 
    struct ev_loop *epoller = ev_loop_new (EVBACKEND_EPOLL | EVFLAG_NOENV);
    if (!epoller)
      fatal ("no epoll found here, maybe it hides under your chair");
 
-=item ev_default_destroy ()
+Example: Use whatever libev has to offer, but make sure that kqueue is
+used if available.
+
+   struct ev_loop *loop = ev_loop_new (ev_recommended_backends () | EVBACKEND_KQUEUE);
+
+=item ev_loop_destroy (loop)
 
-Destroys the default loop (frees all memory and kernel state etc.). None
-of the active event watchers will be stopped in the normal sense, so
-e.g. C<ev_is_active> might still return true. It is your responsibility to
-either stop all watchers cleanly yourself I<before> calling this function,
-or cope with the fact afterwards (which is usually the easiest thing, you
-can just ignore the watchers and/or C<free ()> them for example).
+Destroys an event loop object (frees all memory and kernel state
+etc.). None of the active event watchers will be stopped in the normal
+sense, so e.g. C<ev_is_active> might still return true. It is your
+responsibility to either stop all watchers cleanly yourself I<before>
+calling this function, or cope with the fact afterwards (which is usually
+the easiest thing, you can just ignore the watchers and/or C<free ()> them
+for example).
 
 Note that certain global state, such as signal state (and installed signal
 handlers), will not be freed by this function, and related watchers (such
 as signal and child watchers) would need to be stopped manually.
 
-In general it is not advisable to call this function except in the
-rare occasion where you really need to free e.g. the signal handling
-pipe fds. If you need dynamically allocated loops it is better to use
-C<ev_loop_new> and C<ev_loop_destroy>.
-
-=item ev_loop_destroy (loop)
-
-Like C<ev_default_destroy>, but destroys an event loop created by an
-earlier call to C<ev_loop_new>.
+This function is normally used on loop objects allocated by
+C<ev_loop_new>, but it can also be used on the default loop returned by
+C<ev_default_loop>, in which case it is not thread-safe.
+
+Note that it is not advisable to call this function on the default loop
+except in the rare occasion where you really need to free its resources.
+If you need dynamically allocated loops it is better to use C<ev_loop_new>
+and C<ev_loop_destroy>.
 
-=item ev_default_fork ()
+=item ev_loop_fork (loop)
 
-This function sets a flag that causes subsequent C<ev_run> iterations
-to reinitialise the kernel state for backends that have one. Despite the
+This function sets a flag that causes subsequent C<ev_run> iterations to
+reinitialise the kernel state for backends that have one. Despite the
 name, you can call it anytime, but it makes most sense after forking, in
-the child process (or both child and parent, but that again makes little
-sense). You I<must> call it in the child before using any of the libev
-functions, and it will only take effect at the next C<ev_run> iteration.
+the child process. You I<must> call it (or use C<EVFLAG_FORKCHECK>) in the
+child before resuming or calling C<ev_run>.
 
 Again, you I<have> to call it on I<any> loop that you want to re-use after 
 a fork, I<even if you do not plan to use the loop in the parent>. This is
@@ -628,17 +646,19 @@
 costly reset of the backend).
 
 The function itself is quite fast and it's usually not a problem to call
-it just in case after a fork. To make this easy, the function will fit in
-quite nicely into a call to C<pthread_atfork>:
+it just in case after a fork.
 
-    pthread_atfork (0, 0, ev_default_fork);
+Example: Automate calling C<ev_loop_fork> on the default loop when
+using pthreads.
 
-=item ev_loop_fork (loop)
+   static void
+   post_fork_child (void)
+   {
+     ev_loop_fork (EV_DEFAULT);
+   }
 
-Like C<ev_default_fork>, but acts on an event loop created by
-C<ev_loop_new>. Yes, you have to call this on every allocated event loop
-after fork that you want to re-use in the child, and how you keep track of 
-them is entirely your own problem.
+   ...
+   pthread_atfork (0, 0, post_fork_child);
 
 =item int ev_is_default_loop (loop)
 
@@ -809,9 +829,9 @@
 C<EVBREAK_ONE>, which will make the innermost C<ev_run> call return, or
 C<EVBREAK_ALL>, which will make all nested C<ev_run> calls return.
 
-This "unloop state" will be cleared when entering C<ev_run> again.
+This "break state" will be cleared when entering C<ev_run> again.
 
-It is safe to call C<ev_break> from outside any C<ev_run> calls. ##TODO##
+It is safe to call C<ev_break> from outside any C<ev_run> calls, too.
 
 =item ev_ref (loop)
 
@@ -1106,6 +1126,10 @@
 The event loop has been resumed in the child process after fork (see
 C<ev_fork>).
 
+=item C<EV_CLEANUP>
+
+The event loop is about to be destroyed (see C<ev_cleanup>).
+
 =item C<EV_ASYNC>
 
 The given async watcher has been asynchronously notified (see C<ev_async>).
@@ -1136,65 +1160,6 @@
 
 =back
 
-=head2 WATCHER STATES
-
-There are various watcher states mentioned throughout this manual -
-active, pending and so on. In this section these states and the rules to
-transition between them will be described in more detail - and while these
-rules might look complicated, they usually do "the right thing".
-
-=over 4
-
-=item initialiased
-
-Before a watcher can be registered with the event looop it has to be
-initialised. This can be done with a call to C<ev_TYPE_init>, or calls to
-C<ev_init> followed by the watcher-specific C<ev_TYPE_set> function.
-
-In this state it is simply some block of memory that is suitable for use
-in an event loop. It can be moved around, freed, reused etc. at will.
-
-=item started/running/active
-
-Once a watcher has been started with a call to C<ev_TYPE_start> it becomes
-property of the event loop, and is actively waiting for events. While in
-this state it cannot be accessed (except in a few documented ways), moved,
-freed or anything else - the only legal thing is to keep a pointer to it,
-and call libev functions on it that are documented to work on active watchers.
-
-=item pending
-
-If a watcher is active and libev determines that an event it is interested
-in has occurred (such as a timer expiring), it will become pending. It will
-stay in this pending state until either it is stopped or its callback is
-about to be invoked, so it is not normally pending inside the watcher
-callback.
-
-The watcher might or might not be active while it is pending (for example,
-an expired non-repeating timer can be pending but no longer active). If it
-is stopped, it can be freely accessed (e.g. by calling C<ev_TYPE_set>),
-but it is still property of the event loop at this time, so cannot be
-moved, freed or reused. And if it is active the rules described in the
-previous item still apply.
-
-It is also possible to feed an event on a watcher that is not active (e.g.
-via C<ev_feed_event>), in which case it becomes pending without being
-active.
-
-=item stopped
-
-A watcher can be stopped implicitly by libev (in which case it might still
-be pending), or explicitly by calling its C<ev_TYPE_stop> function. The
-latter will clear any pending state the watcher might be in, regardless
-of whether it was active or not, so stopping a watcher explicitly before
-freeing it is often a good idea.
-
-While stopped (and not pending) the watcher is essentially in the
-initialised state, that is it can be reused, moved, modified in any way
-you wish.
-
-=back
-
 =head2 GENERIC WATCHER FUNCTIONS
 
 =over 4
@@ -1346,7 +1311,6 @@
 
 =back
 
-
 =head2 ASSOCIATING CUSTOM DATA WITH A WATCHER
 
 Each watcher has, by default, a member C<void *data> that you can change
@@ -1412,6 +1376,65 @@
        (((char *)w) - offsetof (struct my_biggy, t2));
    }
 
+=head2 WATCHER STATES
+
+There are various watcher states mentioned throughout this manual -
+active, pending and so on. In this section these states and the rules to
+transition between them will be described in more detail - and while these
+rules might look complicated, they usually do "the right thing".
+
+=over 4
+
+=item initialiased
+
+Before a watcher can be registered with the event looop it has to be
+initialised. This can be done with a call to C<ev_TYPE_init>, or calls to
+C<ev_init> followed by the watcher-specific C<ev_TYPE_set> function.
+
+In this state it is simply some block of memory that is suitable for use
+in an event loop. It can be moved around, freed, reused etc. at will.
+
+=item started/running/active
+
+Once a watcher has been started with a call to C<ev_TYPE_start> it becomes
+property of the event loop, and is actively waiting for events. While in
+this state it cannot be accessed (except in a few documented ways), moved,
+freed or anything else - the only legal thing is to keep a pointer to it,
+and call libev functions on it that are documented to work on active watchers.
+
+=item pending
+
+If a watcher is active and libev determines that an event it is interested
+in has occurred (such as a timer expiring), it will become pending. It will
+stay in this pending state until either it is stopped or its callback is
+about to be invoked, so it is not normally pending inside the watcher
+callback.
+
+The watcher might or might not be active while it is pending (for example,
+an expired non-repeating timer can be pending but no longer active). If it
+is stopped, it can be freely accessed (e.g. by calling C<ev_TYPE_set>),
+but it is still property of the event loop at this time, so cannot be
+moved, freed or reused. And if it is active the rules described in the
+previous item still apply.
+
+It is also possible to feed an event on a watcher that is not active (e.g.
+via C<ev_feed_event>), in which case it becomes pending without being
+active.
+
+=item stopped
+
+A watcher can be stopped implicitly by libev (in which case it might still
+be pending), or explicitly by calling its C<ev_TYPE_stop> function. The
+latter will clear any pending state the watcher might be in, regardless
+of whether it was active or not, so stopping a watcher explicitly before
+freeing it is often a good idea.
+
+While stopped (and not pending) the watcher is essentially in the
+initialised state, that is it can be reused, moved, modified in any way
+you wish.
+
+=back
+
 =head2 WATCHER PRIORITY MODELS
 
 Many event loops support I<watcher priorities>, which are usually small
@@ -2239,7 +2262,7 @@
 
 Signal watchers will trigger an event when the process receives a specific
 signal one or more times. Even though signals are very asynchronous, libev
-will try it's best to deliver signals synchronously, i.e. as part of the
+will try its best to deliver signals synchronously, i.e. as part of the
 normal event processing, like any other event.
 
 If you want signals to be delivered truly asynchronously, just use
@@ -3074,23 +3097,64 @@
 
 When this is not possible, or you want to use the default loop for
 other reasons, then in the process that wants to start "fresh", call
-C<ev_default_destroy ()> followed by C<ev_default_loop (...)>. Destroying
-the default loop will "orphan" (not stop) all registered watchers, so you
-have to be careful not to execute code that modifies those watchers. Note
-also that in that case, you have to re-register any signal watchers.
+C<ev_loop_destroy (EV_DEFAULT)> followed by C<ev_default_loop (...)>.
+Destroying the default loop will "orphan" (not stop) all registered
+watchers, so you have to be careful not to execute code that modifies
+those watchers. Note also that in that case, you have to re-register any
+signal watchers.
 
 =head3 Watcher-Specific Functions and Data Members
 
 =over 4
 
-=item ev_fork_init (ev_signal *, callback)
+=item ev_fork_init (ev_fork *, callback)
 
 Initialises and configures the fork watcher - it has no parameters of any
 kind. There is a C<ev_fork_set> macro, but using it is utterly pointless,
-believe me.
+really.
+
+=back
+
+
+=head2 C<ev_cleanup> - even the best things end
+
+Cleanup watchers are called just before the event loop is being destroyed
+by a call to C<ev_loop_destroy>.
+
+While there is no guarantee that the event loop gets destroyed, cleanup
+watchers provide a convenient method to install cleanup hooks for your
+program, worker threads and so on - you just to make sure to destroy the
+loop when you want them to be invoked.
+
+Cleanup watchers are invoked in the same way as any other watcher. Unlike
+all other watchers, they do not keep a reference to the event loop (which
+makes a lot of sense if you think about it). Like all other watchers, you
+can call libev functions in the callback, except C<ev_cleanup_start>.
+
+=head3 Watcher-Specific Functions and Data Members
+
+=over 4
+
+=item ev_cleanup_init (ev_cleanup *, callback)
+
+Initialises and configures the cleanup watcher - it has no parameters of
+any kind. There is a C<ev_cleanup_set> macro, but using it is utterly
+pointless, I assure you.
 
 =back
 
+Example: Register an atexit handler to destroy the default loop, so any
+cleanup functions are called.
+
+   static void
+   program_exits (void)
+   {
+     ev_loop_destroy (EV_DEFAULT_UC);
+   }
+
+   ...
+   atexit (program_exits);
+
 
 =head2 C<ev_async> - how to wake up an event loop
 
@@ -4706,6 +4770,11 @@
 callback: The watcher callbacks have different type signatures, but libev
 calls them using an C<ev_watcher *> internally.
 
+=item pointer accesses must be thread-atomic
+
+Accessing a pointer value must be atomic, it must both be readable and
+writable in one piece - this is the case on all current architectures.
+
 =item C<sig_atomic_t volatile> must be thread-atomic as well
 
 The type C<sig_atomic_t volatile> (or whatever is defined as
@@ -4821,14 +4890,28 @@
 
 =head1 PORTING FROM LIBEV 3.X TO 4.X
 
-The major version 4 introduced some minor incompatible changes to the API.
+The major version 4 introduced some incompatible changes to the API.
 
-At the moment, the C<ev.h> header file tries to implement superficial
-compatibility, so most programs should still compile. Those might be
-removed in later versions of libev, so better update early than late.
+At the moment, the C<ev.h> header file provides compatibility definitions
+for all changes, so most programs should still compile. The compatibility
+layer might be removed in later versions of libev, so better update to the
+new API early than late.
 
 =over 4
 
+=item C<EV_COMPAT3> backwards compatibility mechanism
+
+The backward compatibility mechanism can be controlled by
+C<EV_COMPAT3>. See L<PREPROCESSOR SYMBOLS/MACROS> in the L<EMBEDDING>
+section.
+
+=item C<ev_default_destroy> and C<ev_default_fork> have been removed
+
+These calls can be replaced easily by their C<ev_loop_xxx> counterparts:
+
+   ev_loop_destroy (EV_DEFAULT_UC);
+   ev_loop_fork (EV_DEFAULT);
+
 =item function/symbol renames
 
 A number of functions and symbols have been renamed:
@@ -4856,12 +4939,6 @@
 C<ev_loop_fork> because it would otherwise clash with the C<ev_fork>
 typedef.
 
-=item C<EV_COMPAT3> backwards compatibility mechanism
-
-The backward compatibility mechanism can be controlled by
-C<EV_COMPAT3>. See L<PREPROCESSOR SYMBOLS/MACROS> in the L<EMBEDDING>
-section.
-
 =item C<EV_MINIMAL> mechanism replaced by C<EV_FEATURES>
 
 The preprocessor symbol C<EV_MINIMAL> has been replaced by a different
@@ -4945,5 +5022,6 @@
 
 =head1 AUTHOR
 
-Marc Lehmann <libev@schmorp.de>, with repeated corrections by Mikael Magnusson.
+Marc Lehmann <libev@schmorp.de>, with repeated corrections by Mikael
+Magnusson and Emanuele Giaquinta.