Як запобігти одній підпроцесі від голодування інших?

Щоб було зрозуміло, я не говорю про те, що повинно вимагати багатомодерності emacs (хоча це, ймовірно, також вирішило б це). Для відтворення:

emacs -Q # Я бігаю 24.4.1
Зробіть другий кадр
Перейти назад до першого кадру
Оболонка Mx
Mx однозначно перейменувати (ми пізніше зробимо другу оболонку)
Почніть працювати: while true; do echo "hello world"; done
У другому кадрі оболонка Mx

Друга оболонка майже ніколи не відображатиметься (рідко вона працює після повторних спроб). Мабуть, emacs ніколи не перерветься з читанням результатів першої оболонки, щоб слухати вихід, який надходить з будь-якого іншого процесу. Було б набагато кращою поведінкою для того, щоб кругообіг, коли існує декілька процесів з очікуваним виходом. Чи є спосіб покращити поведінку?

Єдиним фокусом, який я знаю, було б зробити буфер оболонки власним процесом, але, на жаль, це не спрацює для мене. Навіть якщо я це роблю, мені потрібно запустити підпроцес, щоб прослухати сокет для того, щоб моє програмне забезпечення для розпізнавання мови працювало, щоб я міг реально керувати оболонкою в першу чергу, саме так я і виявив це; запуск нескінченного циклу, як описано вище, запобігає виведенню будь-яких даних з сокета.

shell comint subprocess

— Джозеф Гарвін
джерело

Я не маю конкретної відповіді на ваше запитання. Однак мені подобається використовувати start-processз a set-process-filterі a set-process-sentinel- це дозволяє мені продовжувати свій веселий шлях, роблячи інші речі, поки процес працює - я навіть надсилаю свій вихід іноді в *Messages*буфер, використовуючи insertтак, що моя область ехо не торкається, або я використовую виділений буфер виводу процесу (за потреби). Наприклад, я можу запустити тривалий rsyncсеанс. Я не маю жодного досвіду спроб запустити кілька одночасних / тривалих start-process, тому я не впевнений, як Emacs впорається з усім, що відбувається.

— законник

Хм цікава знахідка. Обидва підсумки оболонки - це окремі процеси, і очевидно, Emacs все ще обробляє основний цикл команд без проблем. Однак я підозрюю, що коли він опитує нижчі FD, він завжди знаходить щось на першій оболонці і ніколи не потрапляє до обробки другого FD. Якщо ви вб'єте час [1] у першій оболонці, друга оболонка дійсно вийде так, як ви очікували. Це, мабуть, питання для списку розсилки розробників.

— stsquad

У мене є ще одна проблема, але це смайлик з кадрами: list.gnu.org/archive/html/bug-gnu-emacs/2015-10/msg01084.html

— ReneFroger

Тож це не правильне рішення, але я провів ваш тест навпаки (наприклад, час [1] на другій оболонці), і він працює добре. У процесі роботи ви могли б гарантувати, що будь-які буфери оболонок, які, ймовірно, генерують важкий вихід, будуть створені пізніше, ніж ті, де потрібно інтерактивність. Таким чином, інтерактивні оболонки першими обробляються нижчим опитуванням Emacs, перш ніж нарешті обробляти той, який генерує багато результатів.

На практиці, якщо ви використовуєте підбірку інтерактивної оболонки, ви, швидше за все, не опинитесь у ситуації, коли так довго зависаєте введення-виведення. Якщо вам регулярно потрібна така річ, можливо, краще перенаправлення виводу у файл, а використання режиму перегляду - краще рішення?

— stsquad
джерело

Проблема тут полягає в тому, що не важко написати нескінченний цикл випадково. Я також вважаю за краще не замислюватися над тим, скільки я планую зробити під час виконання команд. Вся перевага використання Emacs полягає в тому, що все вже в хорошому буфері для збереження :)

— Джозеф Гарвін

@JosephGarvin Я ціную це. Я думаю, що найкраще рішення, якщо Mx report-bug зі своїм відмінним відтворювачем.

— stsquad