[PATCH 3/6] user32: Return WAIT_TIMEOUT in nulldrv_MsgWaitForMultipleObjectsEx.

Zebediah Figura (she/her) zfigura at codeweavers.com
Fri May 14 11:51:58 CDT 2021


On 5/14/21 11:14 AM, Rémi Bernon wrote:
> On 5/14/21 5:54 PM, Zebediah Figura (she/her) wrote:
>> On 5/14/21 6:40 AM, Rémi Bernon wrote:
>>> When there's nothing to wait for.
>>>
>>> Signed-off-by: Rémi Bernon <rbernon at codeweavers.com>
>>> ---
>>>   dlls/user32/driver.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/dlls/user32/driver.c b/dlls/user32/driver.c
>>> index 35e206f5e98..cb9dda6a692 100644
>>> --- a/dlls/user32/driver.c
>>> +++ b/dlls/user32/driver.c
>>> @@ -305,6 +305,7 @@ static void CDECL nulldrv_GetDC( HDC hdc, HWND
>>> hwnd, HWND top_win, const RECT *w
>>>   static DWORD CDECL nulldrv_MsgWaitForMultipleObjectsEx( DWORD
>>> count, const HANDLE *handles, DWORD timeout,
>>>                                                           DWORD mask,
>>> DWORD flags )
>>>   {
>>> +    if (!count && !timeout) return WAIT_TIMEOUT;
>>>       return WaitForMultipleObjectsEx( count, handles, flags &
>>> MWMO_WAITALL,
>>>                                        timeout, flags &
>>> MWMO_ALERTABLE );
>>>   }
>>>
>>
>> Why is this necessary? In fact, won't this give wrong results if there
>> is a queued message available?
>>
> 
> This is just the driver interface, winex11.drv returns the same thing
> when not in a X11 client thread, when there was no X11 event, or when
> events didn't get translated (which I think is not always very accurate).
> 
> Then only place where it would matter most is in wait_message, but it's
> usually called at least with the thread queue handle, so count >= 1 there.
> 
> Then it's otherwise called with count == 0 in PeekMessageW, only to 
try
> peeking again if the first peek failed and if the graphics driver
> indicated it received some events (if it didn't return WAIT_TIMEOUT).
> 
> This is making some test fail here with nulldrv, as it returns an error,
> and so we peek messages again although we should not.
> 
> It could maybe be made more robust and handle the error case in
> PeekMessageW, but I think it's better to make sure the graphics drivers
> behave similarly. It would be nice if this could be factored out but it
> seems difficult.
> 
> There's also another place where the return value is checked, which is
> in check_for_events, called when checking async key state, to decide
> whether to flush or not window surfaces but I don't think it matters.
> 
> For all other call sites, its return value isn't used.

Sorry, I see my mental error, yeah.

It does bother me that this condition includes "!timeout", but as you
say that's true in winex11 too, and we never call it with a 0 count and
nonzero timeout anyway.

(I'd still replace that with "if (!count) Sleep(timeout); return
WAIT_TIMEOUT" if it were me, but...)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210514/1c860c48/attachment.sig>


More information about the wine-devel mailing list