On Fri, 11 Mar 2011, Scott James Remnant wrote:
On Thu, Mar 10, 2011 at 12:25 AM, Andrew Morton
[off-list ref] wrote:
quoted
On Wed, 9 Mar 2011 18:01:09 -0800 Scott James Remnant [off-list ref] wrote:
quoted
quoted
It would be helpful to know if the identified users of this feature
actually find it useful and adequate. __I guess the most common
application is the 1,001 desktop clock widgets. __Do you have any
feedback from any of the owners of those?
cron is another obvious one (or init systems attempting to replace
cron). Having to wakeup and check the time every minute can be
non-conducive to power savings, it would be better if we could just
sleep until the next alarm and be woken up if the time changes in
between.
(That being said, we also need to poll for and/or check for timezone
changes - but those are entirely userspace, so we can deal with that
separately)
Sure, there will be lots of applications.
But what I'm asking isn't "it is a good feature". I'm asking "is the
feature implemented well". Ideally someone would get down and modify
cron to use the interface in this patch.
So I've just been thinking today - and I'm actually not sure whether
this is needed at all for this case.
A good cron implementation is going to set timers according to
CLOCK_REALTIME; in the case where the clock changes forwards, those
timers will fire as part of the clock changing already no? And in the
case where the clock changes backwards, you don't want to re-run old
ones anyway.
Even the hourly/daily cases are actually at a fixed time, so would be
triggered - and a decent implementation wouldn't trigger a given
script more than once.
Yeah, I was wondering about today as well. Though when you set back
your clock several days, stuff might be surprised if it's not woken up
for several days :)
Thanks,
tglx
On Fri, Mar 11, 2011 at 11:56 AM, Thomas Gleixner [off-list ref] wrote:
On Fri, 11 Mar 2011, Scott James Remnant wrote:
quoted
On Thu, Mar 10, 2011 at 12:25 AM, Andrew Morton
[off-list ref] wrote:
quoted
On Wed, 9 Mar 2011 18:01:09 -0800 Scott James Remnant [off-list ref] wrote:
quoted
quoted
It would be helpful to know if the identified users of this feature
actually find it useful and adequate. __I guess the most common
application is the 1,001 desktop clock widgets. __Do you have any
feedback from any of the owners of those?
cron is another obvious one (or init systems attempting to replace
cron). Having to wakeup and check the time every minute can be
non-conducive to power savings, it would be better if we could just
sleep until the next alarm and be woken up if the time changes in
between.
(That being said, we also need to poll for and/or check for timezone
changes - but those are entirely userspace, so we can deal with that
separately)
Sure, there will be lots of applications.
But what I'm asking isn't "it is a good feature". I'm asking "is the
feature implemented well". Ideally someone would get down and modify
cron to use the interface in this patch.
So I've just been thinking today - and I'm actually not sure whether
this is needed at all for this case.
A good cron implementation is going to set timers according to
CLOCK_REALTIME; in the case where the clock changes forwards, those
timers will fire as part of the clock changing already no? And in the
case where the clock changes backwards, you don't want to re-run old
ones anyway.
Even the hourly/daily cases are actually at a fixed time, so would be
triggered - and a decent implementation wouldn't trigger a given
script more than once.
Yeah, I was wondering about today as well. Though when you set back
your clock several days, stuff might be surprised if it's not woken up
for several days :)
I've checked the code, and more importantly, tested the
setting-forward example - timers do indeed fire at the point the clock
is wound forwards. This means there doesn't appear to be a utility for
this patch in the cron case.
In the wound back case, I believe that even current cron goes to some
effort to avoid firing events that have already happened?
Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html