[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44CA453D.20700@zytor.com>
Date: Fri, 28 Jul 2006 10:11:25 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Theodore Tso <tytso@....edu>, Neil Horman <nhorman@...driver.com>,
"H. Peter Anvin" <hpa@...or.com>,
Segher Boessenkool <segher@...nel.crashing.org>,
Dave Airlie <airlied@...il.com>, linux-kernel@...r.kernel.org,
a.zummo@...ertech.it, jg@...edesktop.org
Subject: Re: A better interface, perhaps: a timed signal flag
>
> So maybe what we need is an interface where a particular memory
> location gets incremented when a timeout has happened. It's probably
> enough to say that each thread (task_struct) can have one of these
> (another problem with using /dev/rtc and tieing it directly to
> interrupts is that what happens if two processes want to use this
> facility?), and what hardware timer source gets used is hidden from
> the user application. In fact, depending on the resolution which is
> specified (i.e., 100's of microseconds versus 10's of milliseconds),
> different hardware might get used; we should leave that up to the
> kernel.
>
> The other thing which would be nice is if the application could
> specify whether it is interested in CPU time or wall clock time for
> this timeout.
>
It seems to me that this still assumes that we need to take an interrupt
in the kernel. If so, why not just use the timers already present in
the kernel as opposed to polling gettimeofday()?
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists