Re: gtkclipboard.c

[Yevgen Muntyan <muntyan tamu edu>]

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