Yu Feng wrote: > Hi, everyone, > > I have a question about gtkclipboard.c, there might be a problem. > > Look at these functions > ----------------------------- > [snip] > ------------------------------- > In order to make a blocked operation, the main thread(thread 0) spawns a > new thread(saying, thread 1) to wait for the callback. >
Note that there are no threads involved, main loops are not threads (like, not threads at all). > 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 > Actually the "thread" 1, not 2, but it doesn't matter. If you stop signal emission for some weird reason at that point, then the inner main loop will never terminate. But in normal case both main loops will stop, and the quoted code won't even know who were first; and both callers will get the same clipboard data. > (3) when the callback is invoked again for the other calling, thread 2 > will be killed again This one is what's wrong here. Every callback data instance contains its own main loop, so every main loop will be stopped once. What you're saying would be possible if 'selection-received' signal was emitted recursively on the same clipboard widget, but gtk_clipboard_request_contents() takes care of that. Regards, Yevgen _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list