On Mon, 31 Mar 2008, Mulyadi Santosa wrote:
> Hi
>
> On Sun, Mar 30, 2008 at 9:22 PM, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:
> >
> > i'm sure there's a simple answer to this, but what's the value in
> > calling mod_timer() to reset a timer to expire at the current value of
> > jiffies?
> >
> > $ grep -rw "mod_timer.*jiffies)" *
> > arch/x86/kernel/pci-calgary_64.c: mod_timer(&tbl->watchdog_timer, jiffies);
>
> Humm, to expire somewhere right at the start of next tick or at least
> several microseconds after that?? (due to deferred timer execution).
sure, that's what i thought as well, but depending on the semantics
of how timers work, can't you imagine an implementation that checks
first and realizes right away that you're *already* at that time and
just invokes the handler immediately? i mean, are people making that
kind of call to mod_timer() *assuming* that there will be a time lag,
even if it's a tiny one. that strikes me as a dangerous assumption to
make, don't you think?
the only other reason i can think of for the above is that someone
wants to call a handler *right now* or as soon as possible, but wants
to continue execution anyway. in other words, it just happens to be a
way to asynchronously invoke a handler -- it just *looks* weird.
in any event, i'm just speculating.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
