El modo de procesamiento se define mediante una enumeración en C++, que especifica el comportamiento de la instancia del servicio. Por ejemplo:

/**
 * Modo de procesamiento de llamadas para implementaciones de servicios.
 * Los proveedores de plataforma deben cumplir con esta definición.
 */
enum class ModoProcesamientoLlamadas { POLLING, EVENTO, EVENTO_HILO_UNICO };

Este modo se establece en el constructor de la instancia del servicio y permanece fijo durante su ciclo de vida. Por defecto, se utiliza el modo EVENTO.

Modo POLLING

Cuando se selecciona el modo POLLING, ara::com no invoca automáticamente los métodos del servicio. En su lugar, el desarrollador debe llamar explícitamente a una función para procesar la siguiente solicitud pendiente. Esta función devuelve un objeto Future que indica si se procesó una solicitud:

/**
 * Procesa la siguiente llamada pendiente desde la cola de comunicación.
 * Disponible solo en modo POLLING.
 */
ara::core::Future<bool> ProcesarSiguienteLlamada();</bool>

El Future permite encadenar callbacks para manejar solicitudes de forma secuencial. En aplicaciones de tiempo real, este modo evita activaciones no deseadas del proceso, ya que el procesamiento se inicia solo mediante temporizadores específicos. Sin embargo, implica costos adicionales, como el acceso a colas de solicitudes que pueden residir en espacios de memoria compartida o núcleo, lo que introduce latencia variable.

Modos EVENTO y EVENTO_HILO_UNICO

En los modos EVENTO y EVENTO_HILO_UNICO, ara::com gestiona las llamadas de forma asíncrona. Cuando una solicitud llega, se despacha automáticamente al método correspondiente. La diferencia clave radica en la concurrencia:

• En modo EVENTO, el framework puede ejecutar múltiples métodos simultáneamente usando un pool de hilos. Por ejemplo, si llegan solicitudes para métodos distintos, pueden procesarse en paralelo.
• En modo EVENTO_HILO_UNICO, se garantiza que solo un método se ejecuta a la vez por instancia de servicio. Las solicitudes se encolan y se procesan secuencialmente.

El modo EVENTO_HILO_UNICO es útil cuando los métodos comparten datos y requieren sincronización explícita, evitando la sobrecarga de gestionar múltiples hilos. En contraste, el modo EVENTO maximiza el throughput pero puede aumentar la tasa de cambio de contexto en el sistema operativo.

La elección entre estos modos depende de los requisitos de la aplicación: el modo POLLING ofrece control preciso para entornos de tiempo real, mientras que los modos EVENTO simplifican el desarrollo al delegar la gestión de la concurrencia al framwork.