Re: gtkclipboard.c

Yu Feng wrote:
Hi, everyone,

I have a question about gtkclipboard.c, there might be a problem.

Look at these functions
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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]