Re: [PATCH 5/5] quartzdrv: Implement MsgWaitForMultipleObjectsEx and initial Carbon event handling.

[Alexandre Julliard]

Pierre d'Herbemont  writes:
> -
>    DWORD remaining_timeout = timeout;
> -
>    DWORD acceptable_timeout;
> -
> -
>    /* We can't remain too long without a carbon call,
> -
>       or the application seems to hang for the user */
> -
>    do {
> -
>        if(remaining_timeout > 50 || remaining_timeout == INFINITE)
> -
>            acceptable_timeout = 50;
> -
>        else
> -
>            acceptable_timeout = remaining_timeout;
> -
> -
>        ret = WaitForMultipleObjectsEx( count, handles, flags & MWMO_WAITALL,
> -
>                                    acceptable_timeout, flags & MWMO_ALERTABLE );

I don't think polling is an acceptable way to wait for events. You
really need to get a file descriptor or some other handle that you can
wait on.

[PATCH 5/5] quartzdrv: Implement MsgWaitForMultipleObjectsEx and initial Carbon event handling.

[Pierre d'Herbemont]

On 26 oct. 06, at 12:47, Alexandre Julliard wrote:
> I don't think polling is an acceptable way to wait for events. You
> really need to get a file descriptor or some other handle that you can
> wait on.

I am sure it isn't. But I am not sure of the proper solution. I have  
two ideas:

1) Change wineserver to relay on Carbon events to send (some of its)  
message, instead of interrupting the wine thread while waiting for a  
file descriptor. The wine thread could be waiting via the regular  
carbon run loop for an event, and the wineserver could send a carbon  
event as soon as the fd triggers select() end.

2) Launch a 'carbon' thread which will run the carbon run loop (which  
does not poll), and writes to a fd as soon as it receive events.

I think 2) may be preferred but to have a separate thread that watch  
event and an other that act on the UI tends to be tricky.

Pierre.

[PATCH 5/5] quartzdrv: Implement MsgWaitForMultipleObjectsEx and initial Carbon event handling.

[Alexandre Julliard]

Pierre d'Herbemont  writes:
> - Launch a 'carbon' thread which will run the carbon run loop (which
>
> does not poll), and writes to a fd as soon as it receive events.
>
> I think 2) may be preferred but to have a separate thread that watch
> event and an other that act on the UI tends to be tricky.

In any case you need to support multiple threads acting on the UI, so
that shouldn't be much of an issue. Note that the event thread should
be posting messages, not writing to an fd. It probably means that the
design of many bits of the user code need to be different from x11drv,
which is why I think it's important to get this right before writing
tons of code.