PRJ_CANCEL_COMMAND_CB fonction de rappel (projectedfslib.h)

Avertit le fournisseur qu’une opération par un appel antérieur d’un rappel doit être annulée.

Syntaxe

PRJ_CANCEL_COMMAND_CB PrjCancelCommandCb;

void PrjCancelCommandCb(
  [in] const PRJ_CALLBACK_DATA *callbackData
)
{...}

Paramètres

[in] callbackData

Informations sur l’opération. Les membres callbackData suivants sont nécessaires pour implémenter ce rappel :

Commandid Identifie l’opération à annuler.

Valeur de retour

None

Notes

Chaque appel d’un rappel de fournisseur a un paramètre callbackData avec un champ CommandId . Si un fournisseur fournit une implémentation de ce rappel, il doit effectuer le suivi des valeurs CommandId des rappels qu’il traite de manière asynchrone, c’est-à-dire les rappels à partir desquels il a retourné HRESULT_FROM_WIN32(ERROR_IO_PENDING) mais pas encore terminé en appelant PrjCompleteCommand. Si le fournisseur reçoit ce rappel, cela indique que les E/S qui ont provoqué l’appel du rappel précédent ont été annulées, explicitement ou parce que le thread sur lequel il a été émis s’est arrêté. Le fournisseur doit annuler le traitement de l’appel de rappel identifié par CommandId dès que possible.

L’appel de PrjCompleteCommandpour l’id de commande dans le callbackData de ce rappel n’est pas une erreur, mais il s’agit d’une opération sans opération, car les E/S qui ont provoqué l’appel de rappel identifié par CommandId sont déjà terminées.

ProjFS appelle PRJ_CANCEL_COMMAND_CB pour un CommandId donné uniquement après l’appel du rappel à annuler. Toutefois, si le fournisseur est configuré pour autoriser l’exécution simultanée de plusieurs threads de travail, l’annulation et l’appel d’origine peuvent s’exécuter simultanément. Le fournisseur doit être en mesure de gérer cette situation.

Ce rappel est facultatif. Si le fournisseur ne fournit pas d’implémentation de ce rappel, aucun autre rappel n’est annulable. Le fournisseur traite tous les rappels de manière synchrone.

Spécifications