Synchroon/asynchroon model

Voor de interactieve aard van telefonie moet TAPI een realtime operationele omgeving zijn. Veel van de TAPI-functies zijn vereist om snel te voltooien en hun resultaten synchroon naar de toepassing te retourneren. Andere functies (zoals bellen) kunnen mogelijk niet zo snel worden voltooid en werken daarom asynchroon.

Telefoniebewerkingen worden synchroon of asynchroon uitgevoerd. Deze twee modellen verschillen als volgt. synchrone functies de hele aanvraag uitvoeren voordat de thread van de aanroep van de aanroep van de beller kan worden geretourneerd. Asynchrone functies retourneren voordat de aanvraag volledig is uitgevoerd. Wanneer de asynchrone aanvraag later is voltooid, rapporteert de serviceprovider de voltooiing door een callbackprocedure aan te roepen die TAPI oorspronkelijk vroeg in de initialisatiereeks heeft opgegeven.

• Asynchrone bewerkingen hebben een parameter met de naam dwRequestID van het gedefinieerde type DRV_REQUESTID als eerste parameter. Een dergelijke bewerking voert een deel van de verwerking uit in de functieaanroep en de rest van de verwerking ervan in een onafhankelijke uitvoeringsthread nadat de functieaanroep is geretourneerd. Wanneer de functie wordt geretourneerd, retourneert deze een negatief foutresultaat of de (positieve) dwRequestID die is doorgegeven in de functieaanroep. Het negatieve foutresultaat geeft aan dat de bewerking is voltooid (en mislukt). De positieve dwRequestID geretourneerd, geeft aan dat de bewerking wordt voortgezet in de onafhankelijke thread. In dat geval roept de serviceprovider uiteindelijk de ASYNC_COMPLETION-procedure aan, waarbij de dwRequestID- en een resultaatcode worden doorgegeven om het resultaat van de bewerking aan te geven. De resultaatcode is nul voor succes of een van dezelfde set (negatieve) foutresultaten. In elk geval mag de serviceprovider nooit nul of een andere positieve waarde retourneren dan dwRequestID van een functie die als asynchroon is aangewezen, omdat dit onverwachte resultaten kan opleveren. Serviceproviders moeten altijd invoergegevens uit het toepassingsgeheugen kopiëren naar het geheugen van de serviceprovider voordat ze terugkeren van een asynchrone functie.
• Synchrone bewerkingen hebben geen dwRequestID- als eerste parameter. Een dergelijke bewerking voert alle verwerking uit in de uitvoeringsthread van de aanroeper, waardoor het uiteindelijke resultaat wordt geretourneerd wanneer deze wordt geretourneerd. Het resultaat is nul voor succes of een negatieve foutcode voor fouten. De serviceprovider roept geen ASYNC_COMPLETION aan voor synchrone bewerkingen.

Het is interessant om rekening te houden met de timing van een callback voor voltooiing ten opzichte van wanneer de oorspronkelijke aanvraag wordt geretourneerd. Een typische asynchrone aanvraag wordt door de serviceprovider geïmplementeerd, zoals in de volgende pseudocode:

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
}

Als de bewerking zeer snel wordt voltooid (of de oorspronkelijke aanvraag zeer langzaam retourneert), is het mogelijk dat de interrupthandler die wordt uitgevoerd wanneer een fysieke bewerking is voltooid, kan worden geactiveerd voordat de oorspronkelijke aanvraag terugkeert naar de toepassing of zelfs naar TAPI. Dit gedrag is toegestaan. TAPI garandeert dat de uiteindelijke voltooiingsmelding aan de toepassing wordt bezorgd nadat de oorspronkelijke aanvraag is geretourneerd.

TAPI 2.x: geeft aan welke status elke functie synchroon of asynchroon wordt voltooid in TAPI Quick Function Reference.