[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk
Subject:    Documentation question
From:       Eneko Lacunza <elacunza () pandasoftware ! es>
Date:       2004-10-14 8:40:16
Message-ID: 1097743216.1236.17.camel () bioelacunza
[Download RAW message or body]

Hi All,

First of all I'd want to thank all Glib developers; I have recently
started using it and I think it is an excelent library! :)

I have noticed that in Glib's Devhelp documentation, Glib Core
Application Support -> Threads -> GCond, there is the following example:

--- cut ---
Example 9. Using GCond to block a thread until a condition is satisfied

GCond* data_cond = NULL;   /* Must be initialized somewhere */
GMutex* data_mutex = NULL; /* Must be initialized somewhere */
gpointer current_data = NULL;

void push_data (gpointer data)
{
  g_mutex_lock (data_mutex);
  current_data = data;
  g_cond_signal (data_cond);
  g_mutex_unlock (data_mutex);
}

gpointer pop_data ()
{
  gpointer data;

  g_mutex_lock (data_mutex);
  while (!current_data)
      g_cond_wait (data_cond, data_mutex);
  data = current_data;
  current_data = NULL;
  g_mutex_unlock (data_mutex);
  return data;
}
--- cut ---

Each of the function is to be called from a different thread. I think
the example causes a deadlock, because when the first pop_data() stops
waiting in g_cond_wait, data_mutex is locked, so push_data would never
get the lock for it, an thus will never g_cond_signal so that pop_data
exits the waiting state.

I'd like to know if I'm correct. If not, please I'd like to know why. If
correct, where should I report this bug?

Thanks a lot!

-- 
Eneko Lacunza
O.D.E. Office
Panda Software - Bilbao (Spain) - http://www.pandasoftware.es
_______________________________________________
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
[prev in list] [next in list] [prev in thread] [next in thread]