winex11.drv: Move clipboard handling to a separate thread

[Yuri Khan]

On Wed, Jul 1, 2009 at 21:07, Alexandre Julliard<julliard at winehq.org> wrote:

>> This patch achieves this by creating an auxiliary thread that will run
>> in the same process that puts data on the clipboard and handle X
>> selection messages.

> That looks quite inefficient, especially since you create a new thread
> every time. You should limit this to the cases where it's really
> necessary, using clipboard from command line apps is a very uncommon
> operation.

As I wrote above, this is not limited to console applications. A GUI
application could at any time go into heavy calculations and exhibit
the same issue. I would need libastral to correctly detect all cases
where a separate thread is necessary.

The inefficiency is somewhat mitigated by the fact that, normally, an
application will not repeatedly acquire clipboard ownership in a tight
loop, but rather only do it in response to user input.

I, however, can think of two optimizations:

(1) Create the thread when the application first acquires clipboard
ownership. On ownership loss, put it to sleep and wake it up the next
time it is needed. This will (needlessly?) complicate the code,
though.

(2) Only create the thread when the hwnd passed as parameter to
OpenClipboard() is null, otherwise decide that "they gave us a window
handle -- it better process messages". This will be quite easy to
implement and cover most cases of honest GUI programs.

(Passing NULL to OpenClipboard for purposes of putting data on the
clipboard is actually a hack, explicitly discouraged by the PSDK
documentation -- but a hack widely used, including wine's
dlls/user32/tests/clipboard.c.)

(1+2) These two techniques can also be used simultaneously.

I will start with (2) and present a revised patch. Meanwhile, it is
open to discussion whether (1) is also necessary.