Re: gtkclipboard.c

[Yu Feng <rainwoodman gmail com>]

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
>