Modelo síncrono/assíncrono

A natureza interativa da telefonia exige que a TAPI seja um ambiente operacional em tempo real. Muitas das funções TAPI são necessárias para concluir rapidamente e retornar seus resultados para o aplicativo de forma síncrona. Outras funções (como discagem) podem não ser capazes de concluir tão rapidamente e, portanto, operar de forma assíncrona.

As operações de telefonia são concluídas de forma síncrona ou assíncrona. Estes dois modelos diferem da seguinte forma. As funções síncronas executar a solicitação inteira antes que o thread do chamador possa retornar da chamada de função. As funções assíncronas retornar antes que a solicitação seja executada em sua totalidade. Quando a solicitação assíncrona for concluída posteriormente, o provedor de serviços relatará a conclusão chamando um procedimento de retorno de chamada que a TAPI forneceu originalmente a ele no início da sequência de inicialização.

• As operações assíncronas têm um parâmetro chamado dwRequestID do tipo definido DRV_REQUESTID como seu primeiro parâmetro. Tal operação executa parte de seu processamento na chamada de função e o restante de seu processamento em um thread de execução independente após o retorno da chamada de função. Quando a função retorna, ela retorna um resultado de erro negativo ou o (positivo) dwRequestID que foi passado na chamada de função. O resultado negativo do erro indica que a operação foi concluída (e falhou). O positivo dwRequestID retornado indica que a operação continua no thread independente. Nesse caso, o provedor de serviços eventualmente chama o procedimento ASYNC_COMPLETION, passando o dwRequestID e um código de resultado para indicar o resultado da operação. O código de resultado é zero para sucesso ou um do mesmo conjunto de resultados de erro (negativos). Em qualquer caso, o provedor de serviços nunca deve retornar zero ou qualquer valor positivo diferente de dwRequestID de uma função designada como assíncrona, porque isso pode produzir resultados inesperados. Os provedores de serviços devem sempre copiar dados de entrada da memória do aplicativo para a memória do provedor de serviços antes de retornar de uma função assíncrona.
• As operações síncronas não têm dwRequestID como seu primeiro parâmetro. Tal operação executa todo o seu processamento no thread de execução do chamador, retornando o resultado final quando ele retorna. O resultado é zero para sucesso ou um código de erro negativo para falha. O provedor de serviços não chama ASYNC_COMPLETION para operações síncronas.

É interessante considerar o tempo de um retorno de chamada de "conclusão" em relação a quando a solicitação original retorna. Uma solicitação assíncrona típica seria implementada pelo provedor de serviços como no seguinte pseudocódigo:

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
}

Se a operação for concluída muito rapidamente (ou a solicitação original retornar muito lentamente), é possível que o manipulador de interrupção executado quando uma operação física for concluída possa ser acionado antes que a solicitação original retorne ao aplicativo ou até mesmo ao TAPI. Esse comportamento é permitido. A TAPI garante que a eventual notificação de conclusão do pedido é entregue após o retorno do pedido original.

TAPI 2.x: Listas que indicam se cada função é concluída de forma síncrona ou assíncrona aparecem em de referência de função rápida TAPI.