On Wed, 2004-02-25 at 19:22, Andreas Bombe wrote:
> Trying to design an SQLite backend into it, I'd say that would be nice
> simply for the reason that it would be the right thing to do. As it is
> currently, expensive database operations are moved out of the main
> thread into their own threads.
Right.
> This poses a difficulty for SQLite as the handles can't be be used in
> multiple threads at once, each thread needs its own handle.
If we were switching to SQLite, the way I envison things is that we make
more of an explicit cache layer in the abstract RhythmDB class. So
there'd be:
struct RhythmDBEntry
{
GAtomic refcount;
char *genre;
char *artist;
...
char *title;
int rating;
...
}
This would be exposed to the rest of the code directly, so no more
rhythmdb_entry_get_string (db, ...).
Then the different backends would produce a result set of these. Then
there would be no threading issues, since the RhythmDBEntries would only
be read in the main thread.
We could still use SQLite in a separate thread then too.
> Some
> complications arise from that. The real problem is the design, what
> should have been done is to move the whole GUI out into its own thread
> rather than selectively moving many work related functions out, which is
> a lot less clean.
The GUI is in its own thread - the main one.
> Implementing proper signal handling would be much easier, too. ;-)
I don't think switching threads around will help much with that.
This is a digitally signed message part