Hello!
> What direction to generalize to? :-)
1. Per-CPU timers. It is required for TCP and I even suspect
we have to move to them in 2.4. Ingo has an implemenation
driven by APIC timers.
2. "soft" timers. I.e. when clock source is not TIMER_BH, but
another events f.e. the do_softirq. It is also required now
(but not in main line, luckily), because I removed similar
functionality (qdisc_run_queues) from net_bh and packet
scheduler became too coarce.
3. Alternative to 2 is variable resolution microtimers. Ingo said he
knows how to make them. I have no idea.
> > Maybe it is better to add flag SELF_DESTRUCTABLE to timer_list
> > and to synchronize to timer->running?
>
> Could you elaborate?
It is mail from Rusty, where he supposed to use return value
from timer handler as sign of destruction. It is too ugly, but
idea is right.
Well, add flag, which means that timer can commit suicide.
In all other cases reset timer->running inside run_timer_list.
For self-destructable ones leave this task to client.
Seems, it is enough flexible.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:28 EST