diff options
author | root <root> | 2009-06-30 06:24:38 +0000 |
---|---|---|
committer | root <root> | 2009-06-30 06:24:38 +0000 |
commit | eefc9a09a2ead1bab1ec265a158ea4250535d44e (patch) | |
tree | 088dcc632f34bcaf0e2239ef6d53a2e835f2d14b /ev.pod | |
parent | 0ca732a60d2a2fa1d0fd7526aa267cf0267ed7fc (diff) |
*** empty log message ***
Diffstat (limited to 'ev.pod')
-rw-r--r-- | ev.pod | 16 |
1 files changed, 14 insertions, 2 deletions
@@ -813,7 +813,9 @@ By setting a higher I<io collect interval> you allow libev to spend more time collecting I/O events, so you can handle more events per iteration, at the cost of increasing latency. Timeouts (both C<ev_periodic> and C<ev_timer>) will be not affected. Setting this to a non-null value will -introduce an additional C<ev_sleep ()> call into most loop iterations. +introduce an additional C<ev_sleep ()> call into most loop iterations. The +sleep time ensures that libev will not poll for I/O events more often then +once per this interval, on average. Likewise, by setting a higher I<timeout collect interval> you allow libev to spend more time collecting timeouts, at the expense of increased @@ -825,7 +827,11 @@ Many (busy) programs can usually benefit by setting the I/O collect interval to a value near C<0.1> or so, which is often enough for interactive servers (of course not for games), likewise for timeouts. It usually doesn't make much sense to set it to a lower value than C<0.01>, -as this approaches the timing granularity of most systems. +as this approaches the timing granularity of most systems. Note that if +you do transactions with the outside world and you can't increase the +parallelity, then this setting will limit your transaction rate (if you +need to poll once per transaction and the I/O collect interval is 0.01, +then you can't do more than 100 transations per second). Setting the I<timeout collect interval> can improve the opportunity for saving power, as the program will "bundle" timer callback invocations that @@ -834,6 +840,12 @@ times the process sleeps and wakes up again. Another useful technique to reduce iterations/wake-ups is to use C<ev_periodic> watchers and make sure they fire on, say, one-second boundaries only. +Example: we only need 0.1s timeout granularity, and we wish not to poll +more often than 100 times per second: + + ev_set_timeout_collect_interval (EV_DEFAULT_UC_ 0.1); + ev_set_io_collect_interval (EV_DEFAULT_UC_ 0.01); + =item ev_loop_verify (loop) This function only does something when C<EV_VERIFY> support has been |