Historia de la pregunta.
El servicio de std::future y std::promise llegó con C++11 para formalizar la transferencia de resultados asíncronos entre hilos. En enfoques anteriores, se dependía de la memoria compartida ad-hoc con sincronización manual, lo que hacía que el manejo de excepciones fuera casi imposible a través de los límites de los hilos. El comité de estandarización necesitaba un mecanismo que pudiera capturar cualquier tipo de excepción lanzada en un hilo de trabajo y reproducirla de manera fiel en el hilo de espera sin conocer el tipo estático de la excepción en el momento del almacenamiento.
El problema.
Los objetos de excepción son polimórficos y, por defecto, se asignan en la pila, pero deben sobrevivir al alcance del std::promise que los produjo. Dado que std::future está parametrizado únicamente por el tipo de resultado, no por el tipo de excepción, el estado compartido no puede contener un miembro de excepción de tipo. Además, el hilo consumidor puede sobrevivir al hilo productor, lo que requiere que la excepción persista en un almacenamiento asignado en el montón con semántica de propiedad compartida.
La solución.
El estándar requiere que std::promise utilice std::exception_ptr para capturar excepciones a través de std::current_exception(), que realiza una eliminación de tipo implícita copiando la excepción al montón y almacenando un manejador eliminado por tipo. El estado compartido (un bloque de control con conteo de referencias) retiene este std::exception_ptr, permitiendo que std::future::get() detecte la excepción y la vuelva a lanzar usando std::rethrow_exception().
std::promise<int> prom; auto fut = prom.get_future(); std::thread([&prom]{ try { throw std::runtime_error("Worker failed"); } catch(...) { prom.set_exception(std::current_exception()); } }).detach(); try { int val = fut.get(); // Vuelve a lanzar runtime_error } catch(const std::exception& e) { // Maneja la excepción transportada }
Contexto.
Un marco de computación distribuida requería que los hilos de trabajo procesaran tareas de segmentación de imágenes que podrían fallar debido a excepciones como GPUOutOfMemory o CorruptInputData. El hilo principal necesitaba recibir estas excepciones específicas para activar el procesamiento en la CPU como alternativa o la retransmisión de datos.
Descripción del problema.
Los intentos iniciales usaron std::exception_ptr manualmente pero sufrieron de errores de duración donde las excepciones fueron destruidas mientras aún eran referenciadas por la cola de errores del hilo principal. Los desarrolladores también luchaban por almacenar tipos de excepciones heterogéneos en un solo contenedor de resultados sin sufrir corte de objetos durante el almacenamiento polimórfico.
Solución 1: Colas de excepciones tipadas.
El equipo consideró mantener colas separadas para cada tipo de excepción utilizando plantillas. Esto proporcionó seguridad de tipos, pero requirió std::any para la eliminación de tipos en la cola común, agregando un sobrecosto y complejidad significativos. También rompió la capacidad de capturar excepciones de manera natural con bloques try-catch en el hilo consumidor.
Solución 2: Contenedor de excepciones virtual.
Implementaron una clase abstracta ExceptionBase con clases derivadas parametrizadas almacenadas en std::unique_ptr<ExceptionBase>. Si bien esto permitió almacenamiento polimórfico, requirió lógica de clonación manual para mantener la propiedad compartida entre hilos e introdujo sobrecarga de despacho virtual durante el relanzamiento. El conteo de referencias personalizado era propenso a errores y difícil de hacer seguro para excepciones.
Solución elegida y por qué.
El equipo adoptó std::packaged_task con std::future, que utiliza internamente el mecanismo std::promise/std::exception_ptr. Esto eliminó el código de eliminación de tipo personalizado porque la biblioteca estándar manejaba automáticamente la captura de excepciones y la duración del estado compartido. La elección fue impulsada por la necesidad de seguridad de excepciones sin mantenimiento y el requerimiento de soportar patrones de manejo de excepciones estándar sin clases base personalizadas.
Resultado.
El sistema propagó exitosamente tipos específicos de excepciones a través de los límites de los hilos sin fugas de memoria, incluso durante el redimensionamiento agresivo de grupos de hilos. El hilo principal podía capturar específicamente GPUOutOfMemory mientras se recurría a std::exception para errores desconocidos, manteniendo una separación clara entre la lógica de manejo de errores y la sincronización de hilos.
Pregunta: ¿Por qué std::current_exception() copia el objeto de excepción en lugar de almacenar un puntero al objeto de excepción existente?
Respuesta.
El objeto de excepción en un bloque catch es típicamente una copia temporal creada por el tiempo de ejecución durante la descomposición de la pila. Almacenar un puntero en crudo crearía una referencia colgante una vez que el bloque catch sale y el marco de la pila se destruye. Al copiar la excepción al montón, std::current_exception() asegura que el objeto persista independientemente de la pila del hilo que lanzó la excepción. Esta operación de copia también permite el mecanismo de eliminación de tipos, permitiendo que std::exception_ptr administre el objeto a través de un eliminador eliminado por tipo mientras mantiene la capacidad de volver a lanzar el tipo original exacto más tarde.
Pregunta: ¿Cómo evita std::promise condiciones de carrera entre set_value() y set_exception()?
Respuesta.
El estado compartido contiene una bandera de estado atómica que rastrea si la promesa está satisfecha. Cuando se llama a set_value() o set_exception(), la implementación realiza una operación atómica de comparación e intercambio para cambiar el estado de "no satisfecho" a "listo". Si el estado ya está listo, la operación lanza std::future_error con promise_already_satisfied. Esta transición atómica asegura que el hilo consumidor que observa el estado listo vea un valor o excepción completamente construido, evitando lecturas o escrituras parciales durante el acceso concurrente por parte del productor y el consumidor.
Pregunta: ¿Por qué puede std::exception_ptr sobrevivir tanto al std::promise como al std::future que lo creó?
Respuesta.
std::exception_ptr utiliza conteo de referencias intrusivo en el objeto de excepción en sí, independiente del estado compartido de std::future/std::promise. Este diseño permite que el código de manejo de excepciones almacene errores en registros de larga duración o gestores de errores después de que la operación asíncrona se haya completado y sus objetos asociados de future/promise hayan sido destruidos. El conteo de referencias asegura que el objeto de excepción se destruya solo cuando el último std::exception_ptr que lo referencia se destruya, apoyando casos de uso como informes de errores retrasados o agregación de excepciones a través de múltiples operaciones asíncronas.