Come posso evitare che un sottoprocesso muoia di fame gli altri?


10

Per essere chiari, non sto parlando di qualcosa che dovrebbe richiedere il multithreading di emacs (anche se questo probabilmente risolverebbe anche questo). Per riprodurre:

  1. emacs -Q # Sto correndo il 24.4.1
  2. Crea un secondo fotogramma
  3. Torna al primo fotogramma
  4. Mx shell
  5. Mx rinomina in modo univoco (faremo una seconda shell in seguito)
  6. Inizia a correre: while true; do echo "hello world"; done
  7. Nel secondo frame, shell Mx

La seconda shell non verrà quasi mai visualizzata (raramente funziona dopo ripetuti tentativi). Apparentemente emacs non prenderà mai una pausa dalla lettura dell'output della prima shell per ascoltare l'output proveniente da qualsiasi altro processo. Sarebbe un comportamento molto migliore per il round robin quando ci sono più processi con output in sospeso. C'è un modo per ottenere un comportamento migliore?

L'unico trucco che conosco sarebbe quello di rendere il buffer della shell un suo processo, ma sfortunatamente non funzionerà per me. Anche se lo faccio, devo eseguire un sottoprocesso per ascoltare un socket affinché il mio software di riconoscimento vocale funzioni in modo da poter effettivamente controllare la shell in primo luogo, è così che l'ho scoperto; l'esecuzione di un ciclo infinito come sopra impedisce che qualsiasi dato venga rimosso dal socket.


1
Non ho una risposta specifica alla tua domanda. Tuttavia, mi piace usare start-processcon a set-process-filtere a set-process-sentinel- questo mi permette di andare per la mia strada facendo altre cose mentre il processo è in esecuzione - Mando persino il mio output a volte al *Messages*buffer usando in insertmodo che la mia area di eco non sia toccata, o uso un buffer di output del processo dedicato (se necessario). Ad esempio, posso eseguire una lunga rsyncsessione. Non ho alcuna esperienza nel provare a eseguire più simultaneamente / lunghi start-process, quindi non sono sicuro di come Emacs gestirà una serie di tutti loro in corso.
elenco delle leggi

2
Hmm trovare interessante. Entrambi gli inferi della shell sono processi separati e ovviamente Emacs sta ancora elaborando il suo ciclo di comandi principale senza problemi. Tuttavia, sospetto che quando esegua il polling degli FD inferiori trovi sempre qualcosa sulla prima shell e non riesca mai a elaborare il secondo FD. Se uccidi while [1] nella prima shell, la seconda shell si presenta come ti aspetti. Questa è probabilmente una domanda per la mailing list degli sviluppatori.
stsquad,

Ho un altro problema, ma è smiliair con cornici: lists.gnu.org/archive/html/bug-gnu-emacs/2015-10/msg01084.html
ReneFroger

Risposte:


2

Quindi questa non è una soluzione adeguata, ma ho eseguito il test al contrario (ad es. While [1] sulla seconda shell) e funziona benissimo. Per ovviare a ciò, è possibile garantire che tutti i buffer della shell che potrebbero generare output pesanti vengano creati più tardi rispetto a quelli in cui si desidera l'interattività. In questo modo le shell interattive sono le prime ad essere gestite dal sondaggio inferiore di Emacs prima di gestire finalmente quella che genera un sacco di output.

In pratica, se si esegue una selezione di shell interattive, probabilmente non ci si troverà in una situazione in cui si può bloccare l'I / O per così tanto tempo. Se hai regolarmente bisogno di qualcosa del genere, forse reindirizzare l'output in un file e utilizzare la modalità di visualizzazione è una soluzione migliore?


1
Il problema qui è che non è difficile scrivere un ciclo infinito per caso. Preferirei anche non dover pensare a quanto piano di I / OI fare quando si eseguono i comandi. L'intero vantaggio dell'utilizzo di emacs è che tutto è già in un bel buffer salvabile :)
Joseph Garvin,

1
@JosephGarvin Lo apprezzo. Penso che la soluzione migliore sia per segnalare Mx con il tuo eccellente riproduttore.
stsquad,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.