Modelo sincrónico/asincrónico

La naturaleza interactiva de la telefonía requiere que TAPI sea un entorno operativo en tiempo real. Muchas de las funciones TAPI son necesarias para completarse rápidamente y devolver sus resultados a la aplicación de forma sincrónica. Es posible que otras funciones (como la marcación) no puedan completarse tan rápidamente como funcionen de forma asincrónica.

Las operaciones de telefonía se completan de forma sincrónica o asincrónica. Estos dos modelos difieren de la siguiente manera. funciones sincrónicas ejecutar toda la solicitud antes de que se permita que el subproceso del llamador devuelva desde la llamada de función. funciones asincrónicas devolver antes de que la solicitud se haya ejecutado en su totalidad. Cuando se complete la solicitud asincrónica más adelante, el proveedor de servicios notifica la finalización llamando a un procedimiento de devolución de llamada que TAPI proporcionó originalmente a él al principio de la secuencia de inicialización.

• Las operaciones asincrónicas tienen un parámetro denominado dwRequestID del tipo definido DRV_REQUESTID como primer parámetro. Esta operación realiza parte de su procesamiento en la llamada de función y el resto de su procesamiento en un subproceso de ejecución independiente después de que se haya devuelto la llamada de función. Cuando la función devuelve, devuelve un resultado de error negativo o el dwRequestID que se pasó en la llamada de función. El resultado negativo del error indica que la operación se ha completado (y ha producido un error). El dwRequestID positivo devuelto indica que la operación continúa en el subproceso independiente. En tal caso, el proveedor de servicios finalmente llama al procedimiento ASYNC_COMPLETION, pasando el dwRequestID y un código de resultado para indicar el resultado de la operación. El código de resultado es cero para éxito o uno de los mismos resultados de error (negativos). En cualquier caso, el proveedor de servicios nunca debe devolver cero ni ningún valor positivo distinto de dwRequestID de una función designada como asincrónica porque hacerlo puede producir resultados inesperados. Los proveedores de servicios siempre deben copiar los datos de entrada de la memoria de la aplicación en la memoria del proveedor de servicios antes de devolver desde una función asincrónica.
• Las operaciones sincrónicas no tienen dwRequestID como primer parámetro. Esta operación realiza todo su procesamiento en el subproceso de ejecución del autor de la llamada, devolviendo el resultado final cuando devuelve. El resultado es cero para éxito o un código de error negativo para el error. El proveedor de servicios no llama a ASYNC_COMPLETION para las operaciones sincrónicas.

Es interesante tener en cuenta el tiempo de una devolución de llamada de "finalización" en relación con el momento en que se devuelve la solicitud original. El proveedor de servicios implementaría una solicitud asincrónica típica como en el pseudocódigo siguiente:

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 la operación se completa muy rápidamente (o la solicitud original se devuelve muy lentamente), es posible que el controlador de interrupciones que se ejecute cuando se complete una operación física antes de que la solicitud original vuelva a la aplicación o incluso a TAPI. Este comportamiento se permite. TAPI garantiza que la notificación de finalización final a la aplicación se entregue después de que se devuelva la solicitud original.

TAPI 2.x: Enumera qué indica si cada función se completa de forma sincrónica o asincrónica en referencia de función rápida de TAPI.