Jak mogę zapobiec głodowaniu jednego z podprocesów?

Żeby było jasne, nie mówię o niczym, co wymagałoby wielowątkowości emacsa (choć prawdopodobnie to by również rozwiązało). Powielać:

emacs -Q # Używam 24.4.1
Zrób drugą ramkę
Wróć do pierwszej klatki
Powłoka MX
Unikalna zmiana nazwy MX (później zrobimy drugą powłokę)
Zacznij biec: while true; do echo "hello world"; done
W drugiej ramce powłoka Mx

Druga powłoka prawie nigdy się nie wyświetli (rzadko działa po wielokrotnych próbach). Najwyraźniej emacs nigdy nie zrobi przerwy w czytaniu danych wyjściowych pierwszej powłoki, aby nasłuchiwać danych wyjściowych pochodzących z innych procesów. Byłoby znacznie lepszym zachowaniem, gdyby zaokrąglał robin, gdy istnieje wiele procesów z oczekującymi wynikami. Czy jest jakiś sposób na lepsze zachowanie?

Jedyną sztuczką, jaką znam, jest utworzenie z bufora powłoki własnego procesu, ale niestety to nie zadziała. Nawet jeśli to zrobię, muszę uruchomić podproces, aby odsłuchać gniazdo, w którym moje oprogramowanie do rozpoznawania mowy będzie działało, aby móc w pierwszej kolejności kontrolować powłokę - oto jak to odkryłem; uruchomienie nieskończonej pętli, jak wyżej, zapobiega wyjmowaniu danych z gniazda.

shell comint subprocess

— Joseph Garvin
źródło

Nie mam konkretnej odpowiedzi na twoje pytanie. Lubię jednak używać start-processa set-process-filteri a set-process-sentinel- pozwala mi to robić na wesoło, robiąc inne rzeczy podczas procesu - czasami nawet wysyłam swoje dane wyjściowe do *Messages*bufora, insertdzięki czemu mój obszar echa pozostaje nietknięty, lub używam dedykowany bufor wyjściowy procesu (w razie potrzeby). Na przykład mogę uruchomić długą rsyncsesję. Nie mam doświadczenia w próbie uruchomienia wielu jednoczesnych / długich start-process, więc nie jestem pewien, jak Emacs poradziłby sobie z nimi wszystkimi.

— prawnik

Hmm ciekawe znalezisko. Oba elementy wewnętrzne powłoki są osobnymi procesami i oczywiście Emacs nadal bez problemu przetwarza swoją główną pętlę poleceń. Podejrzewam jednak, że gdy sonduje gorsze FD, zawsze znajduje coś w pierwszej powłoce i nigdy nie może przetworzyć drugiej FD. Jeśli zabijesz chwilę [1] w pierwszej powłoce, druga pocisk rzeczywiście pojawi się zgodnie z oczekiwaniami. Jest to prawdopodobnie pytanie do listy dyskusyjnej deweloperów.

— stsquad

Mam inny problem, ale to smiliair z ramkami: lists.gnu.org/archive/html/bug-gnu-emacs/2015-10/msg01084.html

— ReneFroger

To nie jest właściwe rozwiązanie, ale przeprowadziłem test w drugą stronę (np. While [1] na drugiej powłoce) i działa dobrze. W ramach obejścia problemu możesz upewnić się, że wszelkie bufory powłoki, które prawdopodobnie generują duże dane wyjściowe, są tworzone później niż te, w których chcesz mieć interaktywność. W ten sposób interaktywne powłoki są pierwszymi, które są obsługiwane przez gorszą ankietę Emacsa, zanim ostatecznie obsługują tę, która generuje wiele wyników.

W praktyce, jeśli korzystasz z interaktywnej powłoki, prawdopodobnie nie znajdziesz się w sytuacji, w której ktoś tak długo blokuje wejścia / wyjścia. Jeśli regularnie potrzebujesz czegoś takiego, może przekierowanie danych wyjściowych do pliku i użycie trybu widoku jest lepszym rozwiązaniem?

— stsquad
źródło

Problem w tym, że przypadkiem nie jest trudno napisać nieskończoną pętlę. Wolałbym też nie myśleć o tym, ile planuję zrobić we / wy podczas uruchamiania poleceń. Cała zaleta używania emacsa polega na tym, że wszystko jest już w ładnym buforze, który można zapisać :)

— Joseph Garvin

@JosephGarvin Doceniam to. Myślę, że najlepszym rozwiązaniem jest zgłoszenie błędu Mx za pomocą doskonałego odtwarzacza.

— stsquad