JR, I guess I was a little too literal. I do realize that the timer may fire after the interval that was requested. If I can find some time tomorrow, I'll throw together a changeset that demonstrates what I was trying to write. If it makes sense, we can integrate the fix after 2008.11.
-j On Tue, Nov 18, 2008 at 02:28:43AM +0000, jmr wrote: > J - isn't the problem that self.time_until_next_check can be negative in > is_check_required() if the machine has been off for a few days and then > gets turned back on. The correct solution would seem to be to set the > self.time_until_next_check = self.refresh_period once you know a check > is needed. > > def is_check_required(self): > : > if self.time_until_next_check <= 0: > self.time_until_next_check = self.refresh_period > return True > else: > return False > > The call in: > > def do_next_check(self): > : > if self.time_until_next_check > DAILY_SECS: > next_check_time = DAILY_SECS > > Is ok if the refresh period is > a day and you have the period set to > weekly and the machine is up for more than a day then this ensures the > is_check_required() gets fired everyday the machine is up. > > JR > > > This should be fine as [EMAIL PROTECTED] wrote: > > Negative time doesn't make sense. If next_check_time is <= 0, isn't it > > time to check right now? > > > > If the time_until_next_check is < refresh_period, I think we should > > simply perform the check and then set next_check to now + > > refresh_period. I think that would make this a little easier to follow. > > > > -j > > > > > > On Mon, Nov 17, 2008 at 06:01:14PM -0800, Brock Pytlik wrote: > > > >> Ok, then since we've observed time can be negative, that's the right > >> delay in this situation? Would replacing 0 with 10 make everyone happy? > >> > >> Brock > >> > >> jmr wrote: > >> > >>> Brock if we ever hit next_check_time < 0 and set next_check_time = 0: > >>> > >>> 333 + if next_check_time < 0: > >>> 334 + next_check_time = 0 > >>> > >>> Then you will go into a spin in the call to: > >>> 337 + gobject.timeout_add(0, self.do_next_check) > >>> > >>> This is what was happening in the bug we tracked down last week. > >>> > >>> JR > >>> > >>> Brock Pytlik wrote: > >>> > >>>> Webrev: > >>>> http://cr.opensolaris.org/~bpytlik/ips-5171-v1/ > >>>> > >>>> Bug: > >>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=5171 > >>>> Updatemanager eating 50% of the CPU > >>>> > >>>> This changes so that the next check to check for updates isn't > >>>> scheduled until after the current check for updates happens. > >>>> > >>>> Brock > >>>> _______________________________________________ > >>>> pkg-discuss mailing list > >>>> [email protected] > >>>> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss > >>>> > >>>> > >> _______________________________________________ > >> pkg-discuss mailing list > >> [email protected] > >> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss > >> > > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
