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

[Joshua Haberman <joshua haberman com>]

On Mon, 2003-11-17 at 05:01, Benjamin Otte wrote:
> 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.

Locks are for resources that need to be accessed concurrently.  Neither
the DB nor GDK meets this criteria.  So there are really no locks
involved at all.

> Apart from that the DB thread

What DB thread?  It sounds like Colin is talking about a main thread
that does almost everything, and one other thread that polls the
filesystem but does not read or write the DB directly.

> ...will block UI updates (like redraws,
> which happen in idle handlers) when it does its work, which sounds stupid
> somehow, too.
>
> 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.

Why?

Josh