Re: Re: [Rhythmbox-devel] how is support for threads initialized?

["worm book" <skyhover hotmail com>]

----- Original Message ----- 
From: "Tristan Tarrant"
Sent: Monday, September 05, 2005 11:48 PM
Subject: Re: [Rhythmbox-devel] how is support for threads 
initialized?


On Mon, 2005-09-05 at 16:14 -0700, worm book wrote:

> I am very interested in the way rhythmbox is programmed and 
> works!
> Out of curiosity, "g_thread_init" is no-where called. But when I
> am learning gtk programming, I was told that g_thread_init is
> always needed? Does rhythmbox provide itself thread-safe 
> support?
> Or some other libraries rhythmbox is based on are in charge of
> initializing the thread supports?


Rhythmbox is a Gnome application, therefore it uses 
gnome_program_init()
which takes care of initializing threads

Tristan
------

Thank you for your answer. It seems that "rb_threads_init" also 
overrides the default gdk locking function with a recursive one? 
So I am interested and looked into some code and came across the 
following code in a file called "rb-entry-view.c" which looks like 
using recursive locks:
*****begin code*****
void rb_entry_view_select_none (RBEntryView *view)
{
view->priv->selection_lock = TRUE;
gtk_tree_selection_unselect_all (view->priv->selection);
view->priv->selected_entry = NULL;
view->priv->selection_lock = FALSE;  /* <----lock is FALSE now */
}

void rb_entry_view_select_entry (RBEntryView *view,
      RhythmDBEntry *entry)
{
GtkTreeIter iter;
if (entry == NULL)
 return;
view->priv->selection_lock = TRUE;
rb_entry_view_select_none (view);  /* <----call to the above 
function */

/** <----Now the selection_lock is FALSE, and
* no more protection on selected_entry? **/
if (rhythmdb_query_model_entry_to_iter (view->priv->model,
     entry, &iter)) {
 gtk_tree_selection_select_iter (view->priv->selection, &iter);
}
view->priv->selection_lock = FALSE;
}
*****end code*****

Is the selection_lock a recursive one? Will it cause race 
conditions? Also, I jumped to the position where selection_lock is 
used. It turned out that only the following code uses it:
*****begin code*****
static void
rb_entry_view_selection_changed_cb (GtkTreeSelection *selection,
      RBEntryView *view)
{
......
if (view->priv->selection_lock == TRUE)
 return;
/** else: do something to selected_entry
* without setting selection_lock to TRUE first **/
.....
}
****end code*****

Is it possible that this function is called when the function 
rb_entry_view_select_entry is in the middle of the if branch? Will 
such a situation lead to a thread safty problem?

I am sorry for jumping in around the code randomly because I still 
have no clear clue about the structure of it. The mailing list 
seems focuses on talking about usability, not the place for 
talking about techniques? I am sorry if this lengthy, ignorant 
email isn't sent to the right place.

Best,

Skyhover