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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
