From 2a7a247b8106b570bd193801b4739d5a755ae1c7 Mon Sep 17 00:00:00 2001 From: root Date: Thu, 2 Aug 2012 11:55:28 +0000 Subject: *** empty log message *** --- ev.pod | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) (limited to 'ev.pod') diff --git a/ev.pod b/ev.pod index 1a63c5d..1e28589 100644 --- a/ev.pod +++ b/ev.pod @@ -2964,7 +2964,6 @@ Using an C watcher is almost enough: it will be called on the next event loop iteration. However, that isn't as soon as possible - without external events, your C watcher will not be invoked. - This is where C watchers come in handy - all you need is a single global idle watcher that is active as long as you have one active C watcher. The C watcher makes sure the event loop @@ -3253,11 +3252,11 @@ C. (One might optionally use C, too). Fork watchers are called when a C was detected (usually because whoever is a good citizen cared to tell libev about it by calling -C or C). The invocation is done before the -event loop blocks next and before C watchers are being called, -and only in the child after the fork. If whoever good citizen calling -C cheats and calls it in the wrong process, the fork -handlers will be invoked, too, of course. +C). The invocation is done before the event loop blocks next +and before C watchers are being called, and only in the child +after the fork. If whoever good citizen calling C cheats +and calls it in the wrong process, the fork handlers will be invoked, too, +of course. =head3 The special problem of life after fork - how is it possible? @@ -5313,8 +5312,8 @@ be compatible with libev. Interaction between C and C could complicate things, however. The most portable way to handle signals is to block signals in all threads -except the initial one, and run the default loop in the initial thread as -well. +except the initial one, and run the signal handling loop in the initial +thread as well. =item C must be large enough for common memory allocation sizes -- cgit v1.2.3