Date: Thu, 17 May 2001 16:14:02 -0600 From: Brad Huntting <huntting@glarp.com> To: "David Schwartz" <davids@webmaster.com> Cc: "Brad Huntting" <huntting@glarp.com>, current@FreeBSD.ORG Subject: Re: catching abrupt time changes Message-ID: <200105172214.f4HME2R72919@hunkular.glarp.com> In-Reply-To: Your message of "Thu, 17 May 2001 09:06:09 PDT." <NCBBLIEPOCNJOAEKBEAKMENAPBAA.davids@webmaster.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> The usual platform-independent way to do this is to have a thread > that monitors the system clock. It wakes up every, say, 2 seconds > and makes sure the clock is where it expects it. If the clock isn't > what it expects, it does whatever you need to do in that case. > I fear, however, that this is yet another technique that won't work > properly with user-space threading. I fear that the clock thread's > sleep function will be virtualize into something that won't sleep > for the right amount of time if the system clock is changed. Does > anyone know which sleep function to use to avoid this - or if there > is one? Unfortunately, this is exactly what I'm trying fix. I want cron to _stop_ waking up every 60 seconds. If cron has nothing to do for 5 days, it should sleep for 5 days. And if everything on the system is sleeping for 5 days and the kernel knows this, then mabey we can hibernate the system for 5 days. I know theres allot more to this than just cron (network stuff etc). brad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105172214.f4HME2R72919>