Alan Cox wrote:
> > More hmm... synchronize_bh() doesn't do anything to stop a new BH from
> > starting as soon as it has returned. So it's safe within __global_cli()
> > and it can be used after del_timer() to give del_timer_sync() semantics,
> > but apart from that, what use is it??
> Im thinking
Yes, that will work in process context but can't be globally macro'ed or
inlined onto the original del_timer because extra checking is needed in
IMO, all ~700 uses of del_timer() should use the synchronous version
until they have been audited for del_timer_async()-safety.
> Which happens to avoid the overhead and cost in the normal timer deletion
The cost isn't too high, actually. A memory read in internal_add_timer,
a read and a write in del_timer and four writes in run_timer_list().
Much more cost if the special-case code is triggered, of course. Very
> > BTW2: is there any technical reason why the timer_struct clients haven't
> > been migrated over to use timer_list yet?
> Not that I know of
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:14 EST