Re: [Rhythmbox-devel] rhythmdb post-mortem and future

[Benjamin Otte <in7y118 public uni-hamburg de>]

On Fri, 14 Nov 2003, Colin Walters wrote:

> * Locking
>
> So I want to vastly shrink RhythmDB's use of threads.  I now envison
> just 2 threads (apart from GStreamer).  The first is the main GTK+
> thread.  The second is a thread that just does filesystem work - it will
> read metadata from files, watch directories for changes, recursively
> read directories, and the like.  Both threads have GAsyncQueues where
> they receive updates from the other thread.
>
> The advantage of this scheme is that we don't need any kind of locking
> inside the main GTK+ thread.  Basically the GDK lock and the db lock are
> merged.  The main thread knows that the database will never change under
> its feet when it holds the GDK lock.  It can also do writes (like create
> a new iradio station) without any locking.
> From a periodic idle handler, the main thread will poll the fs thread
> for changes.  It will then perform any actions necessary in the models.
>

Merging the DB lock and the GDK lock sounds incredibly stupid to me,
because both of them do something completely different.
Apart from that the DB thread will block UI updates (like redraws,
which happen in idle handlers) when it does its work, which sounds stupid
somehow, too.
The only good thing with that approach is that because of the one big lock
(tm) you always have db and UI in sync (apart from redraws and not yet
handled GdkEvents ;)), but in that case using threads buys you
next to nothing.
Apart from that people might get the idea that they want to remotely
administer Rhythmbox via Bonobo/D-BUS. Every such action would block the
UI.

My (more difficult) idea would be to have multiple threads accessing the
DB. The DB has one lock.
I'd envision the threads doing the following stuff:
1) UI thread - update UI on DB changes and push jobs into the DB handler.
Never ever writelock the DB.
2) DB thread - handle jobs. Never ever access the GDK lock.
3) optional remote thread - handle remote requests.
4) GStreamer thread - playback. Never ever access any of those locks,
just add jobs to the DB thread.

That way the DB thread would keep the DB up to date and the UI thread
would keep the UI up to date.

Or did it already work that way and was too complicated?

Benjamin