From 1aed9ec72c6ca87f03b9493ae5a179ab9d4c87c0 Mon Sep 17 00:00:00 2001
From: Marc Alexander Lehmann <libev@schmorp.de>
Date: Sun, 11 Oct 2015 15:46:42 +0000
Subject: [PATCH] *** empty log message ***

---
 ev.pod | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/ev.pod b/ev.pod
index b67bc85..bda58f5 100644
--- a/ev.pod
+++ b/ev.pod
@@ -418,8 +418,8 @@ without a system call and thus I<very> fast, but my GNU/Linux system also has
 C<pthread_atfork> which is even faster).
 
 The big advantage of this flag is that you can forget about fork (and
-forget about forgetting to tell libev about forking) when you use this
-flag.
+forget about forgetting to tell libev about forking, although you still
+have to ignore C<SIGPIPE>) when you use this flag.
 
 This flag setting cannot be overridden or specified in the C<LIBEV_FLAGS>
 environment variable.
@@ -691,6 +691,9 @@ watchers (except inside an C<ev_prepare> callback), but it makes most
 sense after forking, in the child process. You I<must> call it (or use
 C<EVFLAG_FORKCHECK>) in the child before resuming or calling C<ev_run>.
 
+In addition, if you want to reuse a loop (via this function of
+C<EVFLAG_FORKCHECK>), you I<also> have to ignore C<SIGPIPE>.
+
 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
 because some kernel interfaces *cough* I<kqueue> *cough* do funny things
-- 
2.39.2