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)
328 + def schedule_next_check_for_checks(self):
I don't quite get the naming here. Can this just be
schedule_next_check()?
-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
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
