Dan Price wrote: > On Mon 17 Nov 2008 at 07:20PM, Brock Pytlik wrote: > >> New webrev: >> http://cr.opensolaris.org/~bpytlik/ips-5171-v2/ >> > > DAILY_SECS = 30? > > (i.e. don't forget to change before putback) > Mhmm, just got tired of flipping it back and forth while testing. > 328 + def schedule_next_check_for_checks(self): > > I don't quite get the naming here. Can this just be > schedule_next_check()? > Nope, maybe I should name it scedule_next_check_to_check_for_updates but that seemed long...
Brock > -dp > > >> 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
