… | |
… | |
811 | |
811 | |
812 | By setting a higher I<io collect interval> you allow libev to spend more |
812 | By setting a higher I<io collect interval> you allow libev to spend more |
813 | time collecting I/O events, so you can handle more events per iteration, |
813 | time collecting I/O events, so you can handle more events per iteration, |
814 | at the cost of increasing latency. Timeouts (both C<ev_periodic> and |
814 | at the cost of increasing latency. Timeouts (both C<ev_periodic> and |
815 | C<ev_timer>) will be not affected. Setting this to a non-null value will |
815 | C<ev_timer>) will be not affected. Setting this to a non-null value will |
816 | introduce an additional C<ev_sleep ()> call into most loop iterations. |
816 | introduce an additional C<ev_sleep ()> call into most loop iterations. The |
|
|
817 | sleep time ensures that libev will not poll for I/O events more often then |
|
|
818 | once per this interval, on average. |
817 | |
819 | |
818 | Likewise, by setting a higher I<timeout collect interval> you allow libev |
820 | Likewise, by setting a higher I<timeout collect interval> you allow libev |
819 | to spend more time collecting timeouts, at the expense of increased |
821 | to spend more time collecting timeouts, at the expense of increased |
820 | latency/jitter/inexactness (the watcher callback will be called |
822 | latency/jitter/inexactness (the watcher callback will be called |
821 | later). C<ev_io> watchers will not be affected. Setting this to a non-null |
823 | later). C<ev_io> watchers will not be affected. Setting this to a non-null |
… | |
… | |
823 | |
825 | |
824 | Many (busy) programs can usually benefit by setting the I/O collect |
826 | Many (busy) programs can usually benefit by setting the I/O collect |
825 | interval to a value near C<0.1> or so, which is often enough for |
827 | interval to a value near C<0.1> or so, which is often enough for |
826 | interactive servers (of course not for games), likewise for timeouts. It |
828 | interactive servers (of course not for games), likewise for timeouts. It |
827 | usually doesn't make much sense to set it to a lower value than C<0.01>, |
829 | usually doesn't make much sense to set it to a lower value than C<0.01>, |
828 | as this approaches the timing granularity of most systems. |
830 | as this approaches the timing granularity of most systems. Note that if |
|
|
831 | you do transactions with the outside world and you can't increase the |
|
|
832 | parallelity, then this setting will limit your transaction rate (if you |
|
|
833 | need to poll once per transaction and the I/O collect interval is 0.01, |
|
|
834 | then you can't do more than 100 transations per second). |
829 | |
835 | |
830 | Setting the I<timeout collect interval> can improve the opportunity for |
836 | Setting the I<timeout collect interval> can improve the opportunity for |
831 | saving power, as the program will "bundle" timer callback invocations that |
837 | saving power, as the program will "bundle" timer callback invocations that |
832 | are "near" in time together, by delaying some, thus reducing the number of |
838 | are "near" in time together, by delaying some, thus reducing the number of |
833 | times the process sleeps and wakes up again. Another useful technique to |
839 | times the process sleeps and wakes up again. Another useful technique to |
834 | reduce iterations/wake-ups is to use C<ev_periodic> watchers and make sure |
840 | reduce iterations/wake-ups is to use C<ev_periodic> watchers and make sure |
835 | they fire on, say, one-second boundaries only. |
841 | they fire on, say, one-second boundaries only. |
|
|
842 | |
|
|
843 | Example: we only need 0.1s timeout granularity, and we wish not to poll |
|
|
844 | more often than 100 times per second: |
|
|
845 | |
|
|
846 | ev_set_timeout_collect_interval (EV_DEFAULT_UC_ 0.1); |
|
|
847 | ev_set_io_collect_interval (EV_DEFAULT_UC_ 0.01); |
836 | |
848 | |
837 | =item ev_loop_verify (loop) |
849 | =item ev_loop_verify (loop) |
838 | |
850 | |
839 | This function only does something when C<EV_VERIFY> support has been |
851 | This function only does something when C<EV_VERIFY> support has been |
840 | compiled in, which is the default for non-minimal builds. It tries to go |
852 | compiled in, which is the default for non-minimal builds. It tries to go |
… | |
… | |
4065 | =item C<double> must hold a time value in seconds with enough accuracy |
4077 | =item C<double> must hold a time value in seconds with enough accuracy |
4066 | |
4078 | |
4067 | The type C<double> is used to represent timestamps. It is required to |
4079 | The type C<double> is used to represent timestamps. It is required to |
4068 | have at least 51 bits of mantissa (and 9 bits of exponent), which is good |
4080 | have at least 51 bits of mantissa (and 9 bits of exponent), which is good |
4069 | enough for at least into the year 4000. This requirement is fulfilled by |
4081 | enough for at least into the year 4000. This requirement is fulfilled by |
4070 | implementations implementing IEEE 754 (basically all existing ones). |
4082 | implementations implementing IEEE 754, which is basically all existing |
|
|
4083 | ones. With IEEE 754 doubles, you get microsecond accuracy until at least |
|
|
4084 | 2200. |
4071 | |
4085 | |
4072 | =back |
4086 | =back |
4073 | |
4087 | |
4074 | If you know of other additional requirements drop me a note. |
4088 | If you know of other additional requirements drop me a note. |
4075 | |
4089 | |