Re: [Rhythmbox-devel] idle rhythmbox

["Peter Robinson" <pbrobinson gmail com>]

Hi James,

On 5/13/07, James Doc Livingston <doclivingston gmail com> 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