And if you want to be really safe, you can make it a "LOOP_OPTIMIZED" option, where the user knows that prematurely breaking from a polling loop with a timeout causes that timeout value not to be honoured correctly, and to use the "fail-safe" version to be certain. The "fail-safe" version can be enabled by default or vice versa.
On 3 September 2010 16:52, Naveen Chawla <[email protected]> wrote: > In very uneven cases you could simply reduce the extrapolation target > to avoid overshoot e.g. aim for 80ms instead of 98ms. It's only taking > the average frequency in very-high-frequency cases, to lighten the > workload as appropriate. In low-frequency cases, you don't need any > extrapolation at all. > > On 3 September 2010 16:35, Martin Sustrik <[email protected]> wrote: >> On 09/03/2010 05:09 PM, Naveen Chawla wrote: >> >>> So for example, if the timeout is 100ms. >>> It starts by very briefly presuming that there's no loop, so it starts >>> calling it on "every" poll call. If a loop has been detected (i.e. 4+ >>> poll calls at regular intervals), it uses the time between calls (e.g. >>> 10 nanoseconds) to defer the next gettimeofday call to e.g. 98ms (i.e. >>> it doesn't call gettimeofday until the next 98,000,000th repetition) >>> and then it uses the time elapsed since that last gettimeofday call >>> (recorded 98,000,000 repetitions ago) to give us an updated loop >>> speed, and how many repetitions until the next gettimeofday should be >>> called again (e.g. to aim now for 99.99999ms, don't call gettimeofday >>> until the 1,999,999th repetition ), and so on. >> >> Ah. Extrapolation. That would break the timeout functionality for the flows >> that are unevenly distributed on the time axis. >> >> Martin >> > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
