Bernhard Loos bernhardloos@googlemail.com writes:
@@ -37,7 +37,11 @@ static HANDLE alarm_event; static BOOL (WINAPI *pDuplicateTokenEx)(HANDLE,DWORD,LPSECURITY_ATTRIBUTES, SECURITY_IMPERSONATION_LEVEL,TOKEN_TYPE,PHANDLE); +static DWORD WINAPI (*pQueueUserAPC)(PAPCFUNC pfnAPC, HANDLE hThread, ULONG_PTR dwData);
+static void CALLBACK user_apc(ULONG_PTR param) +{ +}
That doesn't really test anything. You should check if it's being called in various places.
On Fri, Aug 5, 2011 at 3:34 PM, Alexandre Julliard julliard@winehq.org wrote:
Bernhard Loos bernhardloos@googlemail.com writes:
@@ -37,7 +37,11 @@ static HANDLE alarm_event; static BOOL (WINAPI *pDuplicateTokenEx)(HANDLE,DWORD,LPSECURITY_ATTRIBUTES, SECURITY_IMPERSONATION_LEVEL,TOKEN_TYPE,PHANDLE); +static DWORD WINAPI (*pQueueUserAPC)(PAPCFUNC pfnAPC, HANDLE hThread, ULONG_PTR dwData);
+static void CALLBACK user_apc(ULONG_PTR param) +{ +}
That doesn't really test anything. You should check if it's being called in various places.
-- Alexandre Julliard julliard@winehq.org
It does check it. If the apc got called during an io operation, the operation will fail with ERROR_OPERATION_ABORTED/STATUS_CANCELLED. So if it the operation succeeds with an apc scheduled, the pipe was opened with an nonalerable io mode.
Bernhard Loos bernhardloos@googlemail.com writes:
It does check it. If the apc got called during an io operation, the operation will fail with ERROR_OPERATION_ABORTED/STATUS_CANCELLED. So if it the operation succeeds with an apc scheduled, the pipe was opened with an nonalerable io mode.
That's not a very good check. There can be other reasons why the operation would succeed, for instance if kernel32 retries or things like that. If you want to test for alertable mode, check that user APCs run, not for some other side effect.