Comment empêcher un sous-processus d'en affamer d'autres?

Pour être clair, je ne parle de rien qui devrait nécessiter le multithread d'emacs (bien que cela résoudrait probablement aussi cela). Reproduire:

emacs -Q # J'utilise 24.4.1
Faire un deuxième cadre
Revenir à la première image
Coque MX
Mx renommer de façon unique (nous allons faire un deuxième shell plus tard)
Commencer à courir: while true; do echo "hello world"; done
Dans la deuxième image, coque Mx

Le deuxième shell ne s'affichera presque jamais (il fonctionne rarement après des tentatives répétées). Apparemment, emacs ne prendra jamais de pause pour lire la sortie du premier shell pour écouter la sortie provenant de tout autre processus. Il serait beaucoup plus judicieux de procéder à un round robin lorsqu'il existe plusieurs processus avec une sortie en attente. Existe-t-il un moyen d'obtenir un meilleur comportement?

La seule astuce que je connais serait de faire du shell shell son propre processus, mais malheureusement cela ne fonctionnera pas pour moi. Même si je fais cela, je dois exécuter un sous-processus pour écouter un socket pour que mon logiciel de reconnaissance vocale fonctionne afin que je puisse réellement contrôler le shell en premier lieu, c'est ainsi que j'ai découvert cela; exécuter une boucle infinie comme ci-dessus empêche toute donnée d'être retirée du socket.

shell comint subprocess

— Joseph Garvin
source

Je n'ai pas de réponse précise à votre question. Cependant, j'aime utiliser start-processavec un set-process-filteret un set-process-sentinel- cela me permet de continuer joyeusement en faisant d'autres choses pendant que le processus s'exécute - j'envoie même parfois ma sortie au *Messages*tampon en utilisant de insertsorte que ma zone d'écho soit intacte, ou j'utilise un tampon de sortie de processus dédié (si nécessaire). Par exemple, je peux exécuter une longue rsyncsession. Je n'ai aucune expérience en essayant d'exécuter plusieurs simultanés / longs start-process, donc je ne sais pas comment Emacs gérerait une multitude d'entre eux.

— lawlist

Hmm trouvaille intéressante. Les deux inférieurs du shell sont des processus distincts et, évidemment, Emacs traite toujours sa boucle de commande principale sans problème. Cependant, je soupçonne que lorsqu'il interroge les FD inférieurs, il trouve toujours quelque chose sur le premier shell et ne parvient jamais à traiter le deuxième FD. Si vous tuez le while [1] dans le premier obus, le deuxième obus apparaît en effet comme prévu. C'est probablement une question pour la liste de diffusion des développeurs.

— stsquad

J'ai un autre problème mais il est familier avec les cadres: lists.gnu.org/archive/html/bug-gnu-emacs/2015-10/msg01084.html

— ReneFroger

Ce n'est donc pas une bonne solution mais j'ai exécuté votre test dans l'autre sens (par exemple le while [1] sur le deuxième shell) et cela fonctionne très bien. En guise de solution, vous pouvez vous assurer que tous les tampons de shell susceptibles de générer une sortie importante sont créés plus tard que ceux où vous souhaitez l'interactivité. De cette façon, les shells interactifs sont les premiers à être traités par le sondage inférieur d'Emacs avant de finalement gérer celui qui génère beaucoup de sortie.

En pratique, si vous exécutez une sélection de shell interactif, vous ne serez probablement pas dans une situation où l'on monopolise les E / S aussi longtemps. Si vous avez régulièrement besoin d'une telle chose, peut-être rediriger la sortie dans un fichier et utiliser le mode d'affichage est une meilleure solution?

— stsquad
source

Le problème ici est qu'il n'est pas difficile d'écrire une boucle infinie par accident. Je préférerais également ne pas avoir à penser à la quantité de plans d'E / S que je fais lors de l'exécution des commandes. L'avantage d'utiliser emacs est que tout est déjà dans un joli tampon enregistrable :)

— Joseph Garvin

@JosephGarvin J'apprécie cela. Je pense que la meilleure solution serait de rapporter un bug avec votre excellent reproducteur.

— stsquad