Книга: Искусство программирования для Unix
20.3.5. Конструкция системы управления задачами была плохо реализована
20.3.5. Конструкция системы управления задачами была плохо реализована
Не считая возможности приостанавливать процессы (что само по себе является тривиальным дополнением к планировщику, который мог бы быть сделан довольно безопасно), управление задачами предусмотрено для переключения терминала между несколькими процессами. К сожалению, при этом решается простейшая часть проблемы — определение нажатия клавиши. Вместе с тем сложные части, такие как сохранение и восстановление состояния экрана, передаются приложению.
Действительно хорошая реализация данного средства была бы полностью невидимой для пользовательских процессов: без выделенных сигналов, без необходимости сохранять и восстанавливать режимы терминалов, без необходимости для приложений перерисовывать экран в случайные промежутки времени. Моделью должна быть виртуальная клавиатура, которая иногда подключается к реальной (и блокирует ее, если пользователь запрашивает ввод, когда она не подключена), а также виртуальный экран, который время от времени становится видимым на реальном экране (и может блокировать, а может не блокировать вывод, когда он невидимый), с системой, выполняющей мультиплексирование подобно мультиплексированию доступа к диску, процессору и другим ресурсам, но не влияющей на пользовательские программы в целом[152].
При правильной реализации потребовалось бы, чтобы tty-драйвер Unix не просто поддерживал буфер линии, но и полностью отслеживал текущее состояние экрана. Кроме того, потребовалось бы, чтобы сведения о типах терминалов были известны на уровне ядра (возможно, с помощью процесса демона), для того чтобы оно могло соответствующим образом выполнить восстановление, когда приостановленный процесс снова переводится в приоритетный режим. Последствия неправильной реализации заключаются в том, что ядро не способно отключить сеанс как задачу xterm или Emacs от одного терминала и подключить его к другому терминалу (тип которого мог бы отличаться).
Поскольку использование Unix сместилось в сторону X-дисплеев и эмуляторов терминалов, управление задачами стало сравнительно менее важным и этот вопрос уже не имеет прежней остроты. Однако удручает тот факт, что до сих пор не существует функции приостановления/подключения/отключения. Данная функция могла бы быть полезной для сохранения состояния терминальных сеансов между сеансами регистрации в системе.
Широко распространенная программа с открытым исходным кодом, которая называется screen(1), решает некоторые из этих проблем[153]. Однако поскольку пользователь должен ее вызвать явно, не гарантируется, что ее возможности будут присутствовать в каждом терминальном сеансе. Кроме того, код уровня ядра, который перекрывает ее в функциональной части, не был удален.
- 20.3.1. Unix-файл представляет собой только большой блок байтов
- 20.3.2. Слабая поддержка GUI-интерфейсов в Unix
- 20.3.3. Удаление файлов в Unix необратимо
- 20.3.4. Unix предполагает статичную файловую систему
- 20.3.5. Конструкция системы управления задачами была плохо реализована
- 20.3.6. В Unix API не используются исключительные ситуации
- 20.3.7. Вызовы ioctl(2) и fcntl(2) являются препятствиями
- 20.3.8. Модель безопасности Unix, возможно, слишком примитивна
- 20.3.9. Unix имеет слишком много различных видов имен
- 20.3.10. Файловые системы могут считаться вредными
- 20.3.11. На пути к глобальному адресному пространству Internet
- Основные "рычаги" управления производительностью
- Особенности системы защиты данных в InterBase
- Категорийный менеджмент. Курс управления ассортиментом в рознице
- Установка системы на уже подготовленный жесткий диск
- 1.3. Системы счисления
- 7.4. Модель системы автоматизированного проектирования защиты информации
- 1. Системы управления базами данных
- 4. Полнота системы правил Армстронга
- Наик Дайлип Системы хранения данных в Windows
- Глава 6 Файловые системы
- Глава 10 Возможности подсистемы хранения данных в различных версиях Windows NT
- 4.8 Методы управления Fibre Channel