¿Cómo evito que un subproceso muera de hambre a otros?

Para ser claros, no estoy hablando de nada que requiera que emacs sea multiproceso (aunque eso probablemente también resolvería esto). Reproducir:

emacs -Q # Estoy ejecutando 24.4.1
Hacer un segundo cuadro
Cambiar de nuevo al primer fotograma
Mx shell
Mx rename-uniquely (haremos un segundo shell más tarde)
Comience a correr: while true; do echo "hello world"; done
En el segundo cuadro, Mx shell

El segundo shell casi nunca se mostrará (rara vez funciona después de repetidos intentos). Aparentemente, emacs nunca se tomará un descanso al leer la salida del primer shell para escuchar la salida proveniente de cualquier otro proceso. Sería mucho mejor comportamiento para el round robin cuando hay múltiples procesos con salida pendiente. ¿Hay alguna forma de mejorar el comportamiento?

El único truco que conozco es hacer que el shell buffer sea su propio proceso, pero desafortunadamente eso no funcionará para mí. Incluso si hago eso, tengo que ejecutar un subproceso para escuchar un socket para que mi software de reconocimiento de voz funcione, de modo que pueda controlar el shell en primer lugar, así es como descubrí esto; ejecutar un bucle infinito como el anterior evita que se eliminen datos del zócalo.

shell comint subprocess

— Joseph Garvin
fuente

No tengo una respuesta específica a tu pregunta. Sin embargo, me gusta usar start-processcon ay set-process-filtera set-process-sentinel, esto me permite seguir mi camino feliz haciendo otras cosas mientras se ejecuta el proceso, incluso envío mi salida a veces al *Messages*búfer usando insertpara que mi área de eco no se toque, o uso un búfer de salida de proceso dedicado (si es necesario). Por ejemplo, puedo ejecutar una rsyncsesión larga . No tengo ninguna experiencia tratando de ejecutar múltiples simultáneos / largos start-process, por lo que no estoy seguro de cómo Emacs manejaría una gran cantidad de ellos.

— ley

Hmm interesante hallazgo. Ambos inferiores de shell son procesos separados y, obviamente, Emacs todavía está procesando su bucle de comando principal sin problemas. Sin embargo, sospecho que cuando sondea los FD inferiores siempre encuentra algo en el primer shell y nunca llega a procesar el segundo FD. Si matas el while [1] en el primer caparazón, el segundo capa realmente aparece como esperas. Esta es probablemente una pregunta para la lista de correo de desarrollo.

— stsquad

Tengo otro problema, pero es smiliair con marcos: lists.gnu.org/archive/html/bug-gnu-emacs/2015-10/msg01084.html

— ReneFroger

Entonces, esta no es una solución adecuada, pero ejecuté su prueba al revés (por ejemplo, el while [1] en el segundo shell) y funciona bien. Como solución alternativa, puede asegurarse de que cualquier búfer de shell que probablemente genere una gran producción se cree más tarde que aquellos en los que desea interactividad. De esa manera, los shells interactivos son los primeros en ser manejados por la encuesta inferior de Emacs antes de finalmente manejar el que genera mucha salida.

En la práctica, si está ejecutando una selección de shell interactivo, es probable que no se encuentre en una situación en la que uno acapare la E / S durante tanto tiempo. Si necesita algo así, ¿tal vez redirigir la salida a un archivo y usar el modo de vista es una mejor solución?

— stsquad
fuente

El problema aquí es que no es difícil escribir un bucle infinito por accidente. También preferiría no tener que pensar en cuánto planeo hacer I / OI al ejecutar comandos. Toda la ventaja de usar emacs es que todo ya está en un buen búfer que se puede guardar :)

— Joseph Garvin

@JosephGarvin lo agradezco. Creo que la mejor solución es informar a Mx de errores con su excelente reproductor.

— stsquad