UnregisterWaitEx, fonction (threadpoollegacyapiset.h)

Annule une opération d’attente inscrite émise par la fonction RegisterWaitForSingleObject .

Syntaxe

BOOL UnregisterWaitEx(
  [in]           HANDLE WaitHandle,
  [in, optional] HANDLE CompletionEvent
);

Paramètres

[in] WaitHandle

Handle d'attente. Ce handle est retourné par la fonction RegisterWaitForSingleObject .

[in, optional] CompletionEvent

Handle de l’objet d’événement à signaler lorsque l’opération d’attente a été annulée. Ce paramètre peut être NULL.

Si ce paramètre est INVALID_HANDLE_VALUE, la fonction attend que toutes les fonctions de rappel se terminent avant de revenir.

Si ce paramètre a la valeur NULL, la fonction marque le minuteur pour la suppression et retourne immédiatement. Toutefois, la plupart des appelants doivent attendre la fin de la fonction de rappel pour pouvoir effectuer tout nettoyage nécessaire.

Si l’appelant fournit cet événement et que la fonction réussit ou si la fonction échoue avec ERROR_IO_PENDING, ne fermez l’événement qu’une fois qu’il n’a pas été signalé.

Valeur retournée

Si la fonction réussit, la valeur de retour est différente de zéro.

Si la fonction échoue, la valeur de retour est égale à zéro. Pour obtenir des informations détaillées sur l’erreur, appelez GetLastError.

Remarques

Vous ne pouvez pas effectuer un appel bloquant à UnregisterWaitEx à partir d’une fonction de rappel pour la même opération d’attente. Sinon, le rappel attend la fin de son exécution. En général, un appel bloquant à UnregisterWaitEx crée une dépendance entre le thread actuel et le rappel. Par conséquent, pour effectuer un appel d’annulation d’inscription bloquant sur une autre opération d’attente, vous devez vous assurer que les fonctions de rappel ne dépendent pas les unes des autres et que la deuxième opération d’attente n’effectue pas également un appel d’annulation d’inscription bloquant sur la première opération.

Soyez prudent lorsque vous effectuez un appel UnregisterWaitEx bloquant sur un thread persistant. Si l’opération d’attente en cours d’annulation a été créée avec WT_EXECUTEINPERSISTENTTHREAD, un blocage peut se produire.

Après avoir effectué un appel non bloquant à UnregisterWaitEx, aucune nouvelle fonction de rappel associée à WaitHandle ne peut être mise en file d’attente. Toutefois, il peut y avoir des fonctions de rappel en attente déjà mises en file d’attente vers des threads de travail.

Dans certaines conditions, la fonction échoue avec ERROR_IO_PENDING si CompletionEvent a la valeur NULL. Cela indique qu’il existe des fonctions de rappel en suspens. Ces rappels s’exécutent ou sont en cours d’exécution.

Si CompletionEvent est un handle d’un événement fourni par l’appelant, il est possible que la fonction réussisse, échoue avec ERROR_IO_PENDING ou échoue avec un code d’erreur différent. Si la fonction réussit ou si la fonction échoue avec ERROR_IO_PENDING, l’appelant doit toujours attendre que l’événement soit signalé pour fermer l’événement. Si la fonction échoue avec un code d’erreur différent, il n’est pas nécessaire d’attendre que l’événement soit signalé pour fermer l’événement.

Windows XP : Si CompletionEvent est un handle d’un événement fourni par l’appelant et que la fonction échoue avec ERROR_IO_PENDING, l’appelant doit attendre que l’événement soit signalé pour fermer l’événement. Ce comportement a changé à partir de Windows Vista.

Pour compiler une application qui utilise cette fonction, définissez _WIN32_WINNT comme 0x0500 ou version ultérieure. Pour plus d’informations, consultez Utilisation des en-têtes Windows.

Configuration requise

Condition requise	Valeur
Client minimal pris en charge	Windows XP [applications de bureau uniquement]
Serveur minimal pris en charge	Windows Server 2003 [applications de bureau uniquement]
Plateforme cible	Windows
En-tête	threadpoollegacyapiset.h (inclure Windows.h)
Bibliothèque	Kernel32.lib
DLL	Kernel32.dll

Voir aussi

RegisterWaitForSingleObject

Fonctions de synchronisation

Regroupement des threads