Como evito que um subprocesso passe fome para outros?

Para ser claro, não estou falando de nada que exija que o emacs seja multithread (embora isso provavelmente também resolva isso). Reproduzir:

emacs -Q # Estou executando 24.4.1
Faça um segundo quadro
Voltar ao primeiro quadro
Mx shell
Mx renomear-exclusivamente (vamos fazer um segundo shell mais tarde)
Comece a correr: while true; do echo "hello world"; done
No segundo quadro, o shell Mx

O segundo shell quase nunca será exibido (raramente funciona após tentativas repetidas). Aparentemente, o emacs nunca fará uma pausa na leitura da saída do primeiro shell para ouvir a saída de qualquer outro processo. Seria um comportamento muito melhor para arredondar o robin quando houver vários processos com saída pendente. Existe alguma maneira de obter um melhor comportamento?

O único truque que eu sei seria tornar o shell um buffer para seu próprio processo, mas infelizmente isso não funcionará para mim. Mesmo se eu fizer isso, tenho que executar um subprocesso para ouvir um soquete para o meu software de reconhecimento de fala funcionar, para que eu possa realmente controlar o shell em primeiro lugar, foi assim que descobri; executar um loop infinito como o acima evita que quaisquer dados sejam retirados do soquete.

shell comint subprocess

— Joseph Garvin
fonte

Não tenho uma resposta específica para sua pergunta. No entanto, eu gosto de usar start-processcom a set-process-filtere a set-process-sentinel- isso permite que eu siga meu caminho alegre fazendo outras coisas enquanto o processo é executado - eu até envio minha saída às vezes para o *Messages*buffer usando insertpara que minha área de eco fique intocada ou uso um buffer de saída do processo dedicado (se necessário). Por exemplo, eu posso executar uma rsyncsessão longa . Eu não tenho nenhuma experiência tentando executar vários simultâneos / longos start-process, por isso não tenho certeza de como o Emacs lidaria com muitos deles.

— lawlist

Hmm achado interessante. Ambos os inferiores do shell são processos separados e, obviamente, o Emacs ainda está processando seu loop de comando principal sem problemas. No entanto, suspeito que, ao pesquisar os FDs inferiores, ele sempre encontra algo no primeiro shell e nunca consegue processar o segundo FD. Se você matar o tempo [1] no primeiro shell, o segundo shell realmente aparecerá como o esperado. Esta é provavelmente uma pergunta para a lista de discussão do desenvolvedor.

— Stsquad

Eu tenho um outro problema, mas é smiliair com quadros: lists.gnu.org/archive/html/bug-gnu-emacs/2015-10/msg01084.html

— ReneFroger

Portanto, essa não é uma solução adequada, mas eu executei seu teste ao contrário (por exemplo, enquanto isso [1] no segundo shell) e funciona bem. Como solução alternativa, você pode garantir que todos os buffers de shell que provavelmente geram uma saída pesada sejam criados depois dos que você deseja interatividade. Dessa forma, as conchas interativas são as primeiras a serem tratadas pela pesquisa inferior do Emacs antes de finalmente lidar com a que gera muita produção.

Na prática, se você estiver executando uma seleção de shell interativo, provavelmente não estará em uma situação em que monopolize a E / S por tanto tempo. Se você precisar regularmente disso, talvez redirecionar a saída para um arquivo e usar o modo de exibição seja uma solução melhor?

— stsquad
fonte

A questão aqui é que não é difícil escrever um loop infinito por acidente. Eu também preferiria não ter que pensar em quanto I / OI planeja fazer ao executar comandos. Toda a vantagem de usar o emacs é que tudo já está em um bom buffer para salvar :)

— Joseph Garvin

@JosephGarvin Eu aprecio isso. Eu acho que a melhor solução se Mx reportar bug com seu excelente reprodutor.

— Stsquad