Brock - if we have a negative value then seems more sense to just reset
it to the daily check. Padriag knows this code and can look at it
tomorrow, but this seems to be the most conservative approach to me.
328 + def schedule_next_check_for_checks(self):
329 + if (self.time_until_next_check > DAILY_SECS or
self.time_until_next_check < 0):
330 + next_check_time = DAILY_SECS
331 + else:
332 + next_check_time = self.time_until_next_check
335 + if debug == True:
336 + print "scheduling next check:%s" %
next_check_time
337 +
I agree with J that this seems to negate the check on line 329 and 330.
I'd leave it for now and let Padraig take a look, but this should
address the runaway cpu.
JR
> 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
