Esta crónica ha sido probado por expertos para que tengas la garantía de la exactitud de nuestro contenido.
Solución:
No hay disposiciones para detener otro hilo; ya sea independiente o unible.
La única forma de detener un subproceso es que el subproceso regrese de la función de subproceso inicial.
En este caso particular, sugeriría los siguientes cambios:
- No sueltes el hilo. Crea una instancia en main().
- Agrega un bool valor, y un
std::mutexla bool se inicializa afalse - Cada vez que pase por el bucle interno del subproceso, bloquee el mutex con un
std::unique_locktoma el bool, luego desbloquee el mutex. Después de desbloquear el mutex, si el bool estabatruesalir del bucle y volver. - En main(), antes de salir: bloquee el mutex, configure el bool bandera a
truedesbloquea el mutex, luego únete al hilo
Esto no es perfecto, ya que el segundo subproceso tardará hasta cinco segundos en comprobar el bool bandera, y regreso. Pero, este sería el primer paso.
Puede colocarse debajo del estándar C ++ y usar funciones específicas del sistema operativo, como enviar una señal a su propio proceso mientras configura la máscara de señal para que se entregue solo al hilo desconectado; un controlador puede establecer una bandera que se sondea desde su hilo. Si su rutina principal espera más tiempo que el período de encuesta más un poco, puede adivinar que debería haber terminado ;-P. La misma idea general se puede utilizar con cualquier otro mecanismo de señalización, como una variable indicadora atómica de terminación lo antes posible.
Alternativamente, y sólo como último recurso, hay pthread_cancel y similares Tenga en cuenta que la cancelación asíncrona como esta es una cosa famosamente peligrosa en general: debe tener cuidado de que el hilo que termine no pueda estar en ningún código con recursos bloqueados/tomados o puede tener interbloqueos, fugas y/o comportamiento indefinido . Por ejemplo, su código llama std::this_thread::sleep_for(std::chrono::seconds(5)); – ¿Qué pasa si eso le pide al sistema operativo una devolución de llamada cuando expira el intervalo, pero la función para continuar después usa la pila del subproceso terminado? Un ejemplo en el que puede ser seguro es si el subproceso está procesando números en un bucle dentro de su aplicación.
De lo contrario, la respuesta de Sam documenta una alternativa si evita separar el hilo en primer lugar …
No hay forma de cerrar limpiamente un subproceso desconectado. Hacerlo requeriría esperar a que se complete la limpieza, y solo puede hacerlo si el hilo se puede unir.
Considere, por ejemplo, si el subproceso tiene un mutex que otro subproceso necesita adquirir para cerrarse limpiamente. La única forma de cerrar limpiamente ese subproceso sería inducirlo a liberar ese mutex. Eso requeriría la cooperación del hilo.
Considere si el subproceso ha abierto un archivo y mantiene un bloqueo en ese archivo. Cancelar el hilo dejará el archivo bloqueado hasta que se complete el proceso.
Considere si el subproceso tiene un mutex que protege algún estado compartido y ha puesto ese estado compartido temporalmente en un estado inconsistente. Si finaliza el subproceso, la exclusión mutua nunca se liberará o la exclusión mutua se liberará con los datos protegidos en un estado incoherente. Esto puede causar accidentes.
Necesita la cooperación de un hilo para cerrarlo limpiamente.
Recuerda que te brindamos la opción de decir si te fue de ayuda.