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

----- 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


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)
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)
/** 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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]