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); = NULL;
  results.loop = g_main_loop_new (NULL, TRUE);

  gtk_clipboard_request_contents (clipboard, target, 

  if (g_main_loop_is_running (results.loop))
      g_main_loop_run (results.loop);

  g_main_loop_unref (results.loop);


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

What I can see is that 
(1) another new thread(thread 2) is spawned by thread 1, and stored in
(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?


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