diff options
author | root <root> | 2011-06-13 09:52:36 +0000 |
---|---|---|
committer | root <root> | 2011-06-13 09:52:36 +0000 |
commit | 2d984ba58ba63b062436d51b1c3724fb31e33964 (patch) | |
tree | c78a821ae6beaa4802ab0b88d6d6f6bf4240ea45 /ev.pod | |
parent | f16fbd21ee467f0069e6e9c21be59ec41c9847af (diff) |
*** empty log message ***
Diffstat (limited to 'ev.pod')
-rw-r--r-- | ev.pod | 42 |
1 files changed, 22 insertions, 20 deletions
@@ -610,11 +610,11 @@ hacks). On the negative side, the interface is I<bizarre> - 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<ev_feed_signal> to signal this watcher from another thread, even without knowing which loop owns the signal. -Unlike C<ev_signal> watchers, C<ev_async> works with any event loop, not -just the default loop. - =head3 Queueing C<ev_async> does not support queueing of data in any way. The reason @@ -3333,13 +3330,16 @@ signal or similar contexts (see the discussion of C<EV_ATOMIC_T> 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<ev_async> watchers are level-triggered, set on C<ev_async_send>, -reset when the event loop detects that). +compressed into a single callback invocation (another way to look at +this is that C<ev_async> watchers are level-triggered: they are set on +C<ev_async_send>, 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<ev_async_send> 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<ev_async> 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<ev_async> watchers. In the absence of this define, libev will use C<sig_atomic_t volatile> (from F<signal.h>), 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<iff> there were no other C<ev_async_send> -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 |