Hi James, On 5/13/07, James Doc Livingston <[EMAIL PROTECTED]> wrote: > Hi Peter, > > On Sun, 2007-05-13 at 21:19 +0100, Peter Robinson wrote: > > I've played with this a bit more this afternoon using the blog posts > > that you mentioned. I have no idea whether what I've found is an issue > > but from Federico's blog post the g_timeout_add is seems to be a > > problem. From what I found there seems to be 2 of these that are > > called regularly. I may be barking up the wrong tree though. > > Thanks for looking into this. I'd done a bit of investigation into > Rhythmbox's idle wakeups a while back, and noted some things on a bug: > http://bugzilla.gnome.org/show_bug.cgi?id=399012 > > > > First one is in shell/rb-shell-clipboard.c in the function > > rb_shell_clipboard_idle_poll_deletions, line 764. It seems to call the > > else option regularly (every 0.3 seconds from what I can tell) even > > when RB is doing nothing. Not sure why it needs to do what ever its > > doing with a clipboard every 0.3 seconds. > > This one should be fixed in 0.10.0.
Nope, its not. Well not in the official tarball... knew I should have checked out the latest svn. > > Second one is in rhythmdb/rhythmdb.c in the rhythmdb_idle_poll_events, > > line 2003. When idle it runs the else branch every second. Not sure > > what it does every second but being the DB it may not be fixable. > > This is the hard one. While it is certainly fixable, it's somewhat > complicated to do so. It's been a while since I looked at it, so I might > not be remembering exactly, but basically what happens is: > > The database has many events that must be processed in the main thread, > and those events can be added from any thread. We also process the > events in chunks, and want it to not start processing them more than > once a second. It currently works by having an a thread-safe queue which > the events get places on, and once a second a timeout runs in the main > thread to process them (with some other bits to not block the main > thread too long, etc). > > > A better way to do it would be to have a "schedule event" function which > places the event on the queue, checks if there is already a timeout > active and creates one if not (all in a thread-safe way). The timeout > would do exactly what it does now, except that if it had a run without > processing anything it removes itself. It is important that it removes > itself after a run without processing, not when it drains the queue, so > that it doesn't run more than once a second. > > There are some other minor complications to it as well, which is where I > got stuck last time. I can't remember exactly what they were though. Hmm. I would get stuck a whole lot more... but it was an interesting way to spend a couple of hours of a rainy london afternoon, I've done some basic debugging before but not as detailed as that. Might have to fine some time to try and do some more :-P Pete _______________________________________________ rhythmbox-devel mailing list rhythmbox-devel@gnome.org http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
