Re: [Rhythmbox-devel] State Of The Rhythmbox (3)

[Joshua Haberman <joshua haberman com>]

Thanks for the answers.  I'm still a bit lost in the details and my
unfamiliarity with GTK+, but I feel like your latest plan is more in the
right direction.  It still seems a bit thread-happy to me.  Something
that you might consider is: can you consolidate some of the threads? 
For example, I think all the disk functionality:

* reading the XML file from disk
* walking filesystem trees that are added to the library
* monitoring the filesystem for changes

could live in the same thread, a thread that looks something like
(extremely pseudo code in a C++ style since I am not familiar with GTK):

while(1)
{
    sleep(10);
    if(!filesystem_request_queue->empty()) {
        filesystem_request = filesystem_request_queue->pop();
        switch(filesystem_request.type) {
            case FS_REQUEST_ADD_TO_LIBRARY:
                walk_directory_tree_and_add_files_to_rhythmdb(filesystem_request.path);
                break;
            case FS_REQUEST_OPEN_XML_LIBRARY:
                read_xml_file_and_add_files_to_rhythmdb(filesystem_request.xmlfile);
                break;
            [...]
        }
    }
}

Perhaps you know reasons why this kind of consolidation is not possible.

I'm not sure if FAM is standard enough for Gnome programs to use, but if
so it would be a vastly better mechanism for watching the filesystem
than just stat()int the whole library constantly.

One other suggestion I have is to have a search thread always running
instead of spawning one every time the user initiates a search.  This
sidesteps the problems of making sure these search threads do not become
stale.

Josh