Marc Lehmann wrote:
> On Sun, Nov 04, 2007 at 04:09:08PM -0800, Scott Lamb <[EMAIL PROTECTED]>
> wrote:
>> Have you seen the new Linux timerfd API? Where available, you can wait
>> for CLOCK_MONOTONIC and CLOCK_REALTIME events independently. Beats
>> heuristics,
>
> How? I still need to detect time jumps. If my ev_periodic is to be scheduled
> every minute, on the minute, and somebody resets the time the timer needs to
> be rescheduled. With timerfd I would need to detetc that and remove/insert
> the timer again.
My impression was you could create such a timer like this:
struct itimerspec it = {
.it_value = { .tv_sec = 0, .tv_nsec = 0 },
.it_interval = { .tv_sec = 60, .tv_nsec = 0 },
};
sts = timerfd(my_timerfd, CLOCK_REALTIME, TFD_TIMER_ABSTIME, &it);
and any adjustments are the kernel's responsibility. It is aware of the
adjtime() calls and such as they happen.
I have not tested this myself.
> (You might have no use for periodics for timeouts, but they are designed
> to solve this very problem :)
>
> Besides, having a syscall per timer (or even timer change) would be an
> enourmous overhead for many workloads.
Really? Syscalls aren't really *that* expensive in and of themselves,
and it'd be a rare application that makes an order of magnitude more
timerfd() calls than read()/write() calls.
>
>> and detecting time jumps sound like introducing a lot of extra
>> timeouts.
>
> I don't quite see how that would happen with either timer event currently in
> libev, unless the user code forces it.
>
>> I'd hate to see libev(ent)? show up on PowerTOP after just getting rid
>> of the 5-second timeout.
>
> Now idea what powertop is, but sporiadic servers might use a lot of cpu
> without the kernel ever realising it :)
PowerTOP is a Linux tool for seeing the top causes of timeouts. Recently
people are trying to make better use of processor idle states, so it's
important to not fire timeouts unnecessarily.
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
