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

Reply via email to