Modèle synchrone/asynchrone

La nature interactive de la téléphonie exige que TAPI soit un environnement d’exploitation en temps réel. De nombreuses fonctions TAPI sont nécessaires pour effectuer rapidement et retourner leurs résultats à l’application de manière synchrone. D’autres fonctions (telles que la numérotation) peuvent ne pas être en mesure de s’exécuter aussi rapidement et fonctionnent donc de façon asynchrone.

Les opérations de téléphonie se terminent de manière synchrone ou asynchrone. Ces deux modèles diffèrent comme suit. fonctions synchrones exécuter la requête entière avant que le thread de l’appelant soit autorisé à retourner à partir de l’appel de fonction. fonctions asynchrones retourner avant l’exécution de la requête dans son intégralité. Une fois la requête asynchrone terminée ultérieurement, le fournisseur de services signale l’achèvement en appelant une procédure de rappel fournie à l’origine par TAPI au début de la séquence d’initialisation.

• Les opérations asynchrones ont un paramètre nommé dwRequestID du type défini DRV_REQUESTID comme premier paramètre. Une telle opération effectue une partie de son traitement dans l’appel de fonction et le reste de son traitement dans un thread d’exécution indépendant une fois l’appel de fonction retourné. Lorsque la fonction est retournée, elle retourne un résultat d’erreur négatif ou l'dwRequestID qui a été passé dans l’appel de fonction. Le résultat de l’erreur négative indique que l’opération est terminée (et a échoué). Le dwRequestID positif retourné indique que l’opération se poursuit dans le thread indépendant. Dans ce cas, le fournisseur de services appelle finalement la procédure ASYNC_COMPLETION, en passant le dwRequestID et un code de résultat pour indiquer le résultat de l’opération. Le code de résultat est égal à zéro pour la réussite ou l’un des mêmes résultats d’erreur (négatif). Dans tous les cas, le fournisseur de services ne doit jamais retourner zéro ou aucune valeur positive autre que dwRequestID d’une fonction désignée comme asynchrone, car cela peut produire des résultats inattendus. Les fournisseurs de services doivent toujours copier les données d’entrée de la mémoire de l’application dans la mémoire du fournisseur de services avant de retourner à partir d’une fonction asynchrone.
• Les opérations synchrones n’ont pas dwRequestID comme premier paramètre. Une telle opération effectue tout son traitement dans le thread d’exécution de l’appelant, retournant le résultat final lorsqu’il retourne. Le résultat est égal à zéro pour la réussite ou un code d’erreur négatif en cas d’échec. Le fournisseur de services n’appelle pas ASYNC_COMPLETION pour les opérations synchrones.

Il est intéressant de prendre en compte le minutage d’un rappel « d’achèvement » par rapport au moment auquel la demande d’origine retourne. Une requête asynchrone classique serait implémentée par le fournisseur de services comme dans le pseudocode suivant :

Some_request(Request_ID, ...) {
  check parameters for validity
  check device state for validity
  store Request_ID for Completion Interrupt Handler's use
  manipulate device registers to start physical operation
  return Request_ID  // to indicate asynch operation
}
Operation Completion Interrupt Handler: {
  if operation was successful then
    call "completion" callback passing Request_ID and "success"
  else
    call "completion" callback passing Request_ID and "error num"
  endif
}

Si l’opération se termine très rapidement (ou si la requête d’origine retourne très lentement), il est possible que le gestionnaire d’interruptions qui s’exécute lorsqu’une opération physique se termine peut être déclenché avant que la demande d’origine ne retourne à l’application ou même à TAPI. Ce comportement est autorisé. TAPI garantit que la notification d’achèvement éventuelle à l’application est remise une fois la requête d’origine retournée.

TAPI 2.x : Listes qui indiquent si chaque fonction s’exécute de manière synchrone ou asynchrone dans référence de fonction rapide TAPI.