From 2d984ba58ba63b062436d51b1c3724fb31e33964 Mon Sep 17 00:00:00 2001 From: root Date: Mon, 13 Jun 2011 09:52:36 +0000 Subject: *** empty log message *** --- ev.pod | 42 ++++++++++++++++++++++-------------------- 1 file changed, 22 insertions(+), 20 deletions(-) (limited to 'ev.pod') diff --git a/ev.pod b/ev.pod index 32e9479..ef5b4f6 100644 --- a/ev.pod +++ b/ev.pod @@ -610,11 +610,11 @@ hacks). On the negative side, the interface is I - so bizarre that even sun itself gets it wrong in their code examples: The event polling -function sometimes returning events to the caller even though an error +function sometimes returns events to the caller even though an error occurred, but with no indication whether it has done so or not (yes, it's -even documented that way) - deadly for edge-triggered interfaces where -you absolutely have to know whether an event occurred or not because you -have to re-arm the watcher. +even documented that way) - deadly for edge-triggered interfaces where you +absolutely have to know whether an event occurred or not because you have +to re-arm the watcher. Fortunately libev seems to be able to work around these idiocies. @@ -2025,7 +2025,7 @@ do stuff) the timer will not fire more than once per event loop iteration. =item ev_timer_again (loop, ev_timer *) -This will act as if the timer timed out and restart it again if it is +This will act as if the timer timed out and restarts it again if it is repeating. The exact semantics are: If the timer is pending, its pending status is cleared. @@ -3222,9 +3222,6 @@ of "global async watchers" by using a watcher on an otherwise unused signal, and C to signal this watcher from another thread, even without knowing which loop owns the signal. -Unlike C watchers, C works with any event loop, not -just the default loop. - =head3 Queueing C does not support queueing of data in any way. The reason @@ -3333,13 +3330,16 @@ signal or similar contexts (see the discussion of C in the embedding section below on what exactly this means). Note that, as with other watchers in libev, multiple events might get -compressed into a single callback invocation (another way to look at this -is that C watchers are level-triggered, set on C, -reset when the event loop detects that). +compressed into a single callback invocation (another way to look at +this is that C watchers are level-triggered: they are set on +C, reset when the event loop detects that). -This call incurs the overhead of a system call only once per event loop -iteration, so while the overhead might be noticeable, it doesn't apply to -repeated calls to C for the same event loop. +This call incurs the overhead of at most one extra system call per event +loop iteration, if the event loop is blocked, and no syscall at all if +the event loop (or your program) is processing events. That means that +repeated calls are basically free (there is no need to avoid calls for +performance reasons) and that the overhead becomes smaller (typically +zero) under load. =item bool = ev_async_pending (ev_async *) @@ -4371,10 +4371,11 @@ indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled. =item EV_ATOMIC_T Libev requires an integer type (suitable for storing C<0> or C<1>) whose -access is atomic with respect to other threads or signal contexts. No such -type is easily found in the C language, so you can provide your own type -that you know is safe for your purposes. It is used both for signal handler "locking" -as well as for signal and thread safety in C watchers. +access is atomic and serialised with respect to other threads or signal +contexts. No such type is easily found in the C language, so you can +provide your own type that you know is safe for your purposes. It is used +both for signal handler "locking" as well as for signal and thread safety +in C watchers. In the absence of this define, libev will use C (from F), which is usually good enough on most platforms. @@ -5122,8 +5123,9 @@ watchers becomes O(1) with respect to priority handling. =item Processing signals: O(max_signal_number) Sending involves a system call I there were no other C -calls in the current loop iteration. Checking for async and signal events -involves iterating over all running async watchers or all signal numbers. +calls in the current loop iteration and the loop is currently +blocked. Checking for async and signal events involves iterating over all +running async watchers or all signal numbers. =back -- cgit v1.2.3