--- libev/ev.pod	2009/08/26 17:11:42	1.265
+++ libev/ev.pod	2009/08/31 14:51:48	1.269
@@ -592,7 +592,7 @@
 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>).
+C<ev_loop_new> and C<ev_loop_destroy>.
 
 =item ev_loop_destroy (loop)
 
@@ -706,8 +706,8 @@
 =item ev_loop (loop, int flags)
 
 Finally, this is it, the event handler. This function usually is called
-after you initialised all your watchers and you want to start handling
-events.
+after you have initialised all your watchers and you want to start
+handling events.
 
 If the flags argument is specified as C<0>, it will not return until
 either no event watchers are active anymore or C<ev_unloop> was called.
@@ -2126,12 +2126,21 @@
 While this does not matter for the signal disposition (libev never
 sets signals to C<SIG_IGN>, so handlers will be reset to C<SIG_DFL> on
 C<execve>), this matters for the signal mask: many programs do not expect
-many signals to be blocked.
+certain signals to be blocked.
 
 This means that before calling C<exec> (from the child) you should reset
 the signal mask to whatever "default" you expect (all clear is a good
 choice usually).
 
+The simplest way to ensure that the signal mask is reset in the child is
+to install a fork handler with C<pthread_atfork> that resets it. That will
+catch fork calls done by libraries (such as the libc) as well.
+
+In current versions of libev, you can also ensure that the signal mask is
+not blocking any signals (except temporarily, so thread users watch out)
+by specifying the C<EVFLAG_NOSIGNALFD> when creating the event loop. This
+is not guaranteed for future versions, however.
+
 =head3 Watcher-Specific Functions and Data Members
 
 =over 4