Desbloqueo de lectura síncrona en boost :: asio :: serial_port

Question

Tengo un boost::thread que realiza lecturas sincrónicas en un boost::asio::serial_port. Cuando destruyo una instancia de la clase que contiene ambos, quiero que el subproceso finalice con elegancia incluso si está bloqueado en una llamada de lectura. ¿Cómo puedo hacer esto?

Al mirar docs, probé cancel, pero funciona solo para lecturas/escrituras asincrónicas. Luego probé close, pero recibí una excepción y no era del tipo de la que se puede recuperar. Tal vez usando send_break o native_handle? (Esto es Windows y la portabilidad no es crítico)

actualización: También probé a stop la io_service pasé al constructor del objeto del puerto serie, pero el read, no fue desbloqueado.

Editar: La excepción es en realidad "capturable", pero no me gustaría poner un bloque try/catch dentro de un destructor, y la refactorización del código para hacer el proceso de apagado fuera del destructor daría lugar a una gran cantidad de cambios en capas superiores. Así que solo iría por esta solución si alguna autoridad de Boost dice que no hay otra manera.

Answer 1

No hay forma de desbloquear la lectura síncrona cuando lo solicite.

Hay dos opciones:

• close/shutdown el puerto y capturar una excepción, que se planteó
• uso asíncrono lee y cancel ellos, cuando se apaga su aplicación

El el primero, por supuesto, no es una buena idea, porque no se puede distinguir la aplicación de terminación del error.

Answer 2

Al final, dices que recibes una excepción que "no era del tipo de la que puedes recuperar".

¿Qué significa esto?

La solución parece ser atrapar la excepción. ¿Por qué no puedes hacer eso?

Para el caso en que desea distinguir entre un error y la terminación del programa, establezca un indicador en la terminación del programa antes del cierre. En el manejador de excepciones (catch), revisa la bandera. Si se establece, maneje como terminación del programa, o maneje como error.

Usted dice que no desea colocar un bloque try/catch dentro de un destructor. Esto me parece un extraño prejuicio, pero está bien, hay otras formas.

1. Puede permitir que la excepción se propague hasta el final al bloque catch superior que rodea todo el código, y manejarlo allí. (Usted tiene un bloque try/catch que protege su aplicación completa, por supuesto :-)

2. Otras formas también son posibles ...pero el jefe acaba de caer por