[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87y62pmsj0.fsf@shisha.kicks-ass.net>
Date: Mon, 02 May 2011 11:10:59 +0300
From: Alexander Shishkin <virtuoso@...nd.org>
To: Thomas Gleixner <tglx@...utronix.de>,
Kay Sievers <kay.sievers@...y.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
John Stultz <johnstul@...ibm.com>,
Chris Friesen <chris.friesen@...band.com>,
"Kirill A. Shutemov" <kirill@...temov.name>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Davide Libenzi <davidel@...ilserver.org>
Subject: Re: [RFC][PATCH 1/4] clock_rtoffset: new syscall
On Fri, 29 Apr 2011 19:32:13 +0200 (CEST), Thomas Gleixner <tglx@...utronix.de> wrote:
> Alexander,
>
> On Wed, 27 Apr 2011, Kay Sievers wrote:
> > On Wed, 2011-04-27 at 16:02 +0200, Thomas Gleixner wrote:
> > > On Wed, 27 Apr 2011, Alexander Shishkin wrote:
> > > The completely untested patch below should solve the same problem in a
> > > sane way. Restricted to timerfd, but that really should be sufficient.
> >
> > > Subject: timerfd: Allow timers to be cancelled when clock was set
> > > From: Thomas Gleixner <tglx@...utronix.de>
> > > Date: Wed, 27 Apr 2011 14:16:42 +0200
> >
> > Seems to work fine for me here for the weird "cron timer" case, or the
> > simple "desktop clock" use-case -- where we want to rely on the timer to
> > let the process sleep as long as possible, but wake it up to recalculate
> > the next wakeup in case anything has changed in the meantime.
>
> is that sufficient to solve your problems as well?
Yes, it looks to be.
Thanks,
--
Alex
--
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