Busco a una espera de parada (enviar una excepción) a una promesa que se ejecuta en SIGINT. Los ejemplos que se dan en el documento salga todo el proceso y no sólo un trabajador.
¿Alguien sabe cómo "matar", "desprogramar", "parada" un hilo conductor?
Esto es para una P6-jupyter-kernel problema o este tema REPL .
solución actual se está reiniciando de la réplica, pero no matar el hilo bloqueado
await Promise.anyof(
start {
ENTER $running = True;
LEAVE $running = False;
CATCH {
say $_;
reset;
}
$output :=
self.repl-eval($code,:outer_ctx($!save_ctx),|%adverbs);
},
$ctrl-c
);
Versión corta: no utilizar hilos de este, los procesos de uso. Matando al proceso que se ejecuta probablemente es lo mejor que se puede lograr en esta situación en general.
Respuesta larga: en primer lugar, es útil para aclarar un poco de confusión en la pregunta.
En primer lugar, no hay tal cosa como un "funcionamiento Promise"; una Promisees una estructura de datos para transportar un resultado de una operación asíncrona. Un startbloque es realmente hacer tres cosas:
- Creación de una
Promise(que se evalúa a) - La programación de algún código para ejecutar
- Disponiendo que el resultado de ejecutar ese código es reflejada por mantener o romper el
Promise
Esto puede sonar un poco académico, pero que realmente importa: una Promiseno tiene conciencia de lo que finalmente terminan manteniendo o romperlo.
En segundo lugar, un startbloque no es - al menos con el planificador incorporado - respaldado por un hilo, sino que se ejecuta en el grupo de subprocesos. Incluso si se pudiera encontrar una manera de "llevar" el hilo, el planificador grupo de subprocesos no va a ser feliz con tener uno de los hilos que espera para comer de la cola de trabajo en desaparecer. Se podría escribir su propio programador que realmente funciona hacia atrás con un hilo nuevo cada vez, pero que todavía no es una solución completa: ¿y si el trozo de código que el usuario ha solicitado la ejecución de los horarios de trabajo de su propia, y después awaitde que ? Entonces no hay un hilo para matar a realmente llevar las cosas a un alto.
Vamos a suponer, sin embargo, que nos las apañamos para solucionar todo esto, y nos conseguimos una lista de uno o más hilos que realmente queremos matar sin su cooperación (situaciones cooperativas son bastante fáciles; que utilizar una Promisey tienen sondeo de código que de vez en cuando y diesi es que la cancelación Promisese mantuvo siempre / roto).
Cualquier mecanismo que quiere ser capaz de detener un hilo bloqueado en cualquier cosa (no sólo calcular, sino también de E / S, bloqueos, etc.) tendría una profunda integración y cooperación desde el tiempo de ejecución subyacente (como MoarVM). Por ejemplo, intentar cancelar un hilo que se encuentra realizando la recolección de basura será un desastre (lo más probable deadlocking la máquina virtual en su conjunto). Otras veces cancelación desafortunados podría conducir a daños en la memoria si era medio camino a través de una operación que no es seguro para interrumpir, interbloqueos otra parte si el hilo matado sostenía cerraduras, y así sucesivamente. De esta manera uno puede necesitar algún tipo de mecanismo que apunta a salvo. (Ya tenemos cosas a lo largo de esas líneas en MoarVM saber cuándo es seguro para GC, sin embargo, implica la cancelación diferentes demandas. Probablemente es transversal a numerosas partes del código base VM).
Y eso no es todo: las mismas repeticiones situación a nivel lenguaje Raku también. Lock::AsyncPor ejemplo, no es un tipo de cerradura que el tiempo de ejecución subyacente es consciente. Probablemente el mejor que se puede hacer es tratar de derribar la pila de llamadas y ejecutar todas las LEAVEfásers; de esa manera hay algo de esperanza (si la gente utilizó el .protectmétodo, y si acaba de llamar lockyunlockexplícitamente, estamos perdidos). Pero incluso si se consigue que no se escape recursos (ya una gran pregunta), que todavía no sabemos - en general - si el código matamos ha dejado el mundo en cualquier tipo de estado coherente. En un contexto REPL esto podría conducir a resultados dudosos en las ejecuciones de seguimiento que acceden al mismo estado global. Eso es probablemente molesto, pero lo que realmente me asusta es la gente que utilizan ese mecanismo una cancelación en un sistema de producción - que serán si ponerlo en práctica.
Así que, efectivamente, la implementación de una función de este tipo implicaría que hacer una cantidad significativa de trabajo difícil en el tiempo de ejecución y la propia Rakudo, y el resultado sería un gran footgun (Ni siquiera he enumerado todas las cosas que podrían salir mal, sólo el primer pocos que vino a la mente). Por el contrario, matando a un proceso borra todos los recursos, y un proceso tiene su propio espacio de memoria, así que no hay ningún problema de consistencia tampoco.