Как я могу предотвратить один подпроцесс от голода других?

Чтобы было ясно, я не говорю о чем-то, что должно требовать многопоточности emacs (хотя это, вероятно, также решило бы это). Воспроизвести:

emacs -Q # Я работаю 24.4.1
Сделать второй кадр
Вернитесь к первому кадру
Mx shell
Mx переименовывать однозначно (мы собираемся сделать вторую оболочку позже)
Начните бежать: while true; do echo "hello world"; done
Во втором кадре Mx shell

Вторая оболочка почти никогда не будет отображаться (редко работает после повторных попыток). Очевидно, что emacs никогда не будет делать перерыв в чтении вывода первой оболочки, чтобы прослушать вывод, поступающий от любого другого процесса. Было бы гораздо лучше, если бы он выполнял циклический перебор, когда есть несколько процессов с ожидающим выводом. Есть ли способ улучшить поведение?

Единственная хитрость, которую я знаю, это сделать буфер оболочки своим собственным процессом, но, к сожалению, у меня это не сработает. Даже если я сделаю это, мне придется запустить подпроцесс для прослушивания сокета, чтобы моя программа распознавания речи работала, чтобы я мог фактически контролировать оболочку, вот как я это обнаружил; выполнение бесконечного цикла, как описано выше, предотвращает удаление любых данных из сокета.

shell comint subprocess

— Джозеф Гарвин
источник

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

— законник

Хм интересная находка. Оба подчиненных оболочки являются отдельными процессами, и, очевидно, Emacs все еще обрабатывает свой основной командный цикл без проблем. Однако я подозреваю, что когда он опрашивает подчиненные FD, он всегда находит что-то в первой оболочке и никогда не попадает в обработку второго FD. Если вы убьете while [1] в первой оболочке, вторая оболочка действительно появится так, как вы ожидаете. Вероятно, это вопрос к списку рассылки dev.

— stsquad

У меня есть другая проблема, но это смайлик с фреймами: lists.gnu.org/archive/html/bug-gnu-emacs/2015-10/msg01084.html

— ReneFroger

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

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

— stsquad
источник

Проблема здесь в том, что нетрудно написать бесконечный цикл случайно. Я также предпочел бы не думать о том, сколько I / OI планирует делать при выполнении команд. Преимущество использования emacs в том, что все уже находится в хорошем сохраняемом буфере :)

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

@JosephGarvin Я ценю это. Я думаю, что лучшее решение, если Mx report-bug с вашим отличным воспроизводителем.

— Stsquad