Thanks Michal, comments below: Michal Pryc wrote: > John, > I am not sure why the: > > 214 + while gtk.events_pending(): > 215 + gtk.main_iteration(False) > > is inside the loop: > 213 + for pkg, state in > sorted(image_obj.inventory(all_known = True)): Agree this is overkill, it was in side the loop in the UM GUI as more list manipulation was being done in the UM GUI, this is not required here, so happy to drop it.
Will make the change and submit to the gate. > > This loop doesn't touch gui, so IMHO it's just too much, maybe this > was done for some reason, then I am ok with that but otherwise I would > put this gtk.events_pending before the 213 line. > > The rest looks fine for me, but I am not sure if this solves the > eating CPU on startup problem, becuse I was not able to reproduce this > in the previous version. This does not solve the CPU eating issue, it addresses a specific bug to do with spurious notifications #3834. The other bug #3835 will be investigated tomorrow, when I'm back from holiday :) JR > > best > Michal > > John Rice wrote: >> Thanks J - I filed two separate bugs here. One for the issue I uncovered >> about spurious notifications and that's what this webrev addresses. >> >> 3834:UpdateManager Notifier incorrect notification >>> http://cr.opensolaris.org/~jmr/um_notifier_3834_v1_Oct010 >>> >> >> On review on the UM code I noticed that the fetching of the inventory >> data was not yielding to the gtk main loop as often as it should so just >> added in the pending calls as good practice when processing any long >> running task in a PyGTK app. The webrev resolves the spurious >> notifications and I'd like to get that back into the gate. It does not >> address Dan's issue logged below: >> >> 3835: UpdateManager Notifier eating CPU on startup >> >> This CPU eating issue needs further investigation as you rightly point >> out. As I said I did not see it on b98, but clearly it is happening on >> b99 so I will look into this on my return from hols on Tuesday and see >> whats going on. >> >> JR >> >> >> [EMAIL PROTECTED] wrote: >>> Hi John, >>> >>> I put the relevant portion of Dan's comments inline. >>> >>> | Third, once I started the updatemanagernotifier by hand, it ate a >>> lot of >>> | CPU. >>> | >>> | It seems to make from 25,000 syscalls/second to 200,000 syscalls/sec >>> | and is the top process on my system. This looks like a broken call >>> | to poll: >>> | >>> | # truss -c -p `pgrep update` >>> | ^C >>> | syscall seconds calls errors >>> | ioctl .201 27169 >>> | pollsys .192 27275 >>> | -------- ------ ---- >>> | sys totals: .393 54444 0 >>> | usr time: .541 >>> | elapsed: 3.940 >>> >>> >>>> Also want to yield when checking for updates to gtk main loop to help >>>> reduce cpu hogging. >>>> >>> >>>> http://cr.opensolaris.org/~jmr/um_notifier_3834_v1_Oct010 >>>> >>> I took a look at this webrev, but it's unclear to me how calling >>> events_pending() more frequently is going to reduce the number of >>> pollsys syscalls. >>> >>> gtk_events_pending() eventually calls g_main_context_pending (in Glib). >>> This function retrieves the context and then calls >>> g_main_context_iterate(). The context_iterate function sets up a bunch >>> of state, and eventually calls g_main_context_poll(). That function >>> actually invokes the poll syscall. >>> >>> It seems like further investigation should occur before we declare this >>> issue closed. >>> >>> Thanks, >>> >>> -j >>> >> >> _______________________________________________ >> 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
