Thank you for the clearify! but I am still confused. On Mon, 2008-03-31 at 02:22 -0500, Yevgen Muntyan wrote: > Yu Feng wrote:
> Note that there are no threads involved, main loops > are not threads (like, not threads at all). Yes. They shouldn't be threads at least for on some platforms, but will they act very similar as threads? > > > 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, I got the idea. The inner main loop(thread 1) is stored in result->loop. However I discovered that finally result->loop is stored into a qdata in set_request_contents_info. Then the callback stops the inner main loop given in qdata. If there is a re-entrance(so we create a inner inner loop, was the thread2 ) from the inner main loop, will the qdata be corrupted? It will be overwritten by the new value and we lose the old 'result' data, do we? In other words, I am now worrying about the callback data instance instead of the main loop reference. > 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 So the inner main loop is spawned from a signal handler, which may be in-recursive or recursive. The above consideration is about the recursive signal handlers. Let's consider if the signal can't be emitted recursively. Will the inner main loop be blocked or will it delay or ignore the signal? If the inner main loop get blocked, where as the outer main loop is waiting for the inner main loop to quit, we will end up with two blocked main loops and a frozen application. I hope this is not the case and I am wrong somewhere again. > 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
