gtkclipboard.c

[Yu Feng <rainwoodman gmail com>]

Hi, everyone,

I have a question about gtkclipboard.c, there might be a problem.

Look at these functions
-----------------------------
GtkSelectionData *
gtk_clipboard_wait_for_contents (GtkClipboard *clipboard,
				 GdkAtom       target)
{
  WaitResults results;

  g_return_val_if_fail (clipboard != NULL, NULL);
  g_return_val_if_fail (target != GDK_NONE, NULL);
  
  results.data = NULL;
  results.loop = g_main_loop_new (NULL, TRUE);

  gtk_clipboard_request_contents (clipboard, target, 
				  clipboard_received_func,
				  &results);

  if (g_main_loop_is_running (results.loop))
    {
      GDK_THREADS_LEAVE ();
      g_main_loop_run (results.loop);
      GDK_THREADS_ENTER ();
    }

  g_main_loop_unref (results.loop);

  return results.data;
}

static void 
clipboard_received_func (GtkClipboard     *clipboard,
			 GtkSelectionData *selection_data,
			 gpointer          data)
{
  WaitResults *results = data;

  if (selection_data->length >= 0)
    results->data = gtk_selection_data_copy (selection_data);
  
  g_main_loop_quit (results->loop);
}
-------------------------------
In order to make a blocked operation, the main thread(thread 0) spawns a
new thread(saying, thread 1) to wait for the callback. 

but what will happen if in a rared case, the spawned thread handles an
event, and makes another function call to
gtk_clipboard_wait_for_contents?

What I can see is that 
(1) another new thread(thread 2) is spawned by thread 1, and stored in
results->loop. 
(2) when the callback is invoked, either for the first calling or the
second calling, thread 2 will be killed
(3) when the callback is invoked again for the other calling, thread 2
will be killed again and, since it is already destroyed, gtk will panic,
also, since we loose the track of thread 1, thread 0 will never wake up
again, and all the events will be dispatched by thread 1. 

Is this the case? Shall there be a fix?


Yu