Это такой старый вопрос, давайте попробуем. Как я понял, вы используете механизм защиты от тупиков ( this ), чтобы избежать остановки ваших обычных процессов из-за вашего RT-процесса.
Вы говорите, что
у меня есть простая работа, которая требует не более миллисекунды или около того процессорного времени на вызов
Это короткая периодическая задача или короткая задача, запускаемая внешним входом?
Для первого случая ( краткосрочные задачи ): вы должны знать, что в Linux ядре 3.14 стало доступно SCHED_DEADLINE
]класс. Это позволяет вам установить политику планирования для ваших процессов, чтобы у них периодически выделялось как минимум столько процессорного времени. Взгляните на его документацию , вы также найдете понятную диаграмму в разделе SCHED_DEADLINE
в man 7 sched . Если триггер внешний (случайный, а не периодический), то он не может быть решением.
Для второго случая ( короткая спорадическая задача ): если вы можете утверждать, что ваша программа будет выполнять только короткую работу каждый раз, когда это необходимо, вы можете попробовать отказаться от использования приоритетов и просто позвонить по номеру sched_yield после того, как ваша работа будет сделана. Это ба-подход, если занятый пул. Если вам действительно нужны приоритеты, то, возможно, вы можете дополнить его usleep , процессы, не относящиеся к rt, будут выполняться, пока этот процесс RT спит. Вы также можете знать, что если он запускается прерываниями, то, возможно, вам следует использовать нижние половины , более сложный подход.
Мммм и кое-что еще: вы должны иметь в виду, что может появиться больше процессов реального времени, чем у вас. Например, есть потоки ядра .
Я полагаю, что одна из веских причин для наличия дополнительных эмуляторов терминала заключается в том, что если вы сделаете что-то не так в графическом интерфейсе, и он станет непригодным для использования, вы можете быстро переключиться на эмулятор терминала и исправить все проблемы, которые возникают в графическом интерфейсе. На самом деле это случается довольно часто, когда вы вносите изменения в свой оконный менеджер или другие функции графического интерфейса. Я полагаю, было бы также полезно иметь еще пару терминалов, но с 6 Перекрытие основного графического интерфейса кажется излишним.
Также поправьте меня, если я ошибаюсь, но разве нельзя запускать несколько команд от имени разных пользователей с одного эмулятора терминала?
Многие другие вопросы, кажется, дают ответ, почему эта функция была введена.
Тем не менее, актуальный вопрос таков:
Почему Unix / Linux предоставляет несколько эмуляторов терминала?
«делает», а не «делает».
Итак, если сосредоточиться на текущем времени, вот несколько текущих причин:
Таким образом, просто не так много причин не поддерживать это. Есть некоторые преимущества, которые некоторые люди ценят, по крайней мере, иногда, и при этом они не требуют больших затрат.
На самом деле, удаление опоры для этого может потребовать больше усилий, чем просто оставить опору там. Хотя удаление поддержки, вероятно, будет простым, если что-то сломается, выявить и устранить проблему может быть немного сложно. Таким образом, уменьшение количества требуемых усилий (для разработки следующей версии операционной системы) - еще одна причина оставить все как есть. Это означает, что эта функция может оставаться доступной.
Почему UNIX / Linux предоставляет несколько эмуляторов терминала [на консоли]?
По той же причине ваш эмулятор терминала с графическим интерфейсом, вероятно, поддерживает вкладки (например, терминал GNOME), а если нет (например, rxvt
), то по той же причине запуск второго экземпляра приложения GUI-терминала не просто выводит первый на передний план и завершается, заставляя вас использовать первый экземпляр.
Обычно я использую как минимум 3 окна терминала в своей работе, а часто и больше:
Текстовый редактор для серверной части системы, над которой я работаю
Текстовый редактор для клиентской части той же системы
Командное окно для запуска сервера
Мне редко нужен четвертый терминал для запуска клиентской программы, поскольку он обычно работает где-то еще (веб-приложение, приложение с собственным графическим интерфейсом, мобильное приложение и т. Д.), Но если бы я разрабатывал CLI клиент для моего серверного приложения, я бы тоже открыл для него отдельный терминал.
Раньше, до того, как sudo
стал популярным, я постоянно держал терминал root
открытым.
В наши дни я редко использую Unix / Linux в интерактивном режиме на консоли без графического интерфейса пользователя, но я часто запускаю их без подключения к Интернету и обращаюсь к ним через SSH. Мой предпочтительный клиент терминала SSH поддерживает вкладки, настроенные, как указано выше.
В одном из моих текущих хобби-проектов я иногда использую настоящий старый стеклянный терминал , а это значит, что у меня больше нет нескольких окон терминала, поэтому я, наконец, немного узнаю о GNU screen
, программа, которую я никогда особо не использовал раньше, поскольку у меня было либо несколько консольных терминалов, либо несколько терминалов с графическим интерфейсом.А что делает экран
? Помимо прочего, вы можете настроить его так, чтобы он отображал несколько виртуальных терминалов на одном экране, как это делает Linux с помощью Ctrl - Alt - F х .
Первое, о чем вы спросили, - это функция ядра под названием Linux. Не Unix вообще и не Gnu.
А почему, спросите авторов. Однако я предполагаю, что это позволяет администратору устройства, не подключенного к сети (здесь я включаю RS232 как тип сети), входить в систему и выполнять некоторую административную работу, не выходя из системы другого пользователя.
Это функция, предоставляемая почти всеми, если не всеми Unix и Unix, работающими на оборудовании x86. Интересно, что виртуальные консоли впервые были представлены в Unix компанией Microsoft Xenix в начале восьмидесятых, а также были доступны в параллельной версии CP/M.
Позже эта функция была интегрирована в AT&T SVR4 Unix, Solaris и заимствована BSD и Linux.
Why does UNIX/Linux provide multiple terminal emulators?
Когда они были впервые представлены, для машин, на которых выполнялись эти реализации Unix, не было графической среды. В то время как физический терминал, подключенный к центральному серверу Unix через линии RS232, был стандартом, подключение нескольких терминалов к стандартному ПК с Xenix было излишним, если цель заключалась только в том, чтобы один пользователь мог одновременно запускать несколько интерактивных программ. Виртуальные терминалы стали элегантным и удобным решением этой проблемы.
Другие реализации Unix позже предоставили ту же функцию для удовлетворения той же потребности.
Когда графические среды, особенно X11, распространились, возможность видеть несколько эмуляторов терминала одновременно на одном экране стала значительным улучшением. Однако функция виртуальной консоли в целом сохранялась хотя бы потому, что по-прежнему было удобно иметь возможность переключаться на консоль, если графическая среда по какой-то причине зависла или перестала работать.
Обратите внимание, что такие утилиты, как screen
и tmux
, появились намного позже, чем виртуальные терминалы, чтобы обобщить ту же функциональность. Их преимущество в том, что их можно использовать не только на локальной физической консоли, но и в любом сеансе, локальном или удаленном (, например. telnet
, ssh
). При использовании на физической консоливиртуальные консоли по-прежнему полезны, поскольку они работают в некоторых ситуациях, когда screen
/ tmux
не могут помочь, например, если X11 зависает или если окно захватило фокус и не отпускает его.
Виртуализация на основе контейнеров, такая как зоны Solaris или Linux LXC, также предоставляет способ подключения к консоли контейнера через zlogin -C zone
и lxc-console -t 0 -n container
соответственно.