\chapter{Межзадачное взаимодействие}
\label{IPC}

\section{Определения}
В предыдущих разделах мы достаточно свободно использовали
термины <<программа>>, <<процесс>> и <<задача>>. Пришло время,
когда мы вынуждены ввести определения.

Понятие программы интуитивно очевидно -- это набор команд,
который можно загрузить в память и на который можно передать управление.
Часто программой называют цельный загрузочный модуль. Для систем типа
\sysname{MS~DOS} или \sysname{UNIX} такое определение может быть разумным,
и в этом смысле мы можем назвать \sysname{MS~DOS} многопрограммной системой,
но для систем с динамической сборкой оно просто не имеет смысла.

Процесс представляет собой программу,
которая исполняется последовательно. При этом ее исполнение может быть
прервано передачей управления другому процессу, но после этого
оно должно быть возобновлено с той точки, где прервалось.
В операционных системах \sysname{OS/2} и \sysname{Windows~NT}
определенному таким образом процессу соответствует понятие
\termin{нити}{thread}.

Задача представляет собой сочетание программы и данных. При этом
задачи изолированы друг от друга. Если позволяет аппаратура процессора,
то задачи обычно имеют отдельные виртуальные адресные пространства.
Однако мы можем говорить о задачах и на процессорах без диспетчера
памяти, например, на транспьютере. Там все задачи имеют общее виртуальное
адресное пространство, совпадающее с физическим, но из-за особенностей
архитектуры процессора и инструментального языка \progname{Occam} разделение
памяти между процессами крайне затруднено и практически не используется.

Точнее говоря, задачи могут разделять код программы, но
каждая задача обязана иметь собственную копию локальных
(\verb"auto" в терминах языка C) и статических (\verb"static" и
\verb"extern") данных. Вообще-то задачи могут иметь разделяемые данные,
но такое разделение организуется специальными средствами.

Понятно, что в рамках одной задачи может исполняться несколько
процессов. С другой стороны, можно привести пример многозадачной
однопроцессной операционной системы -- \sysname{MS~Windows~3.x}.

{\small
Действительно, в \sysname{MS~Windows~3.1} в \verb"standard" и
\verb"enhanced" режимах каждая запущенная программа формирует отдельную
задачу со своим адресным пространством. Однако для этой программы не
создается иллюзии последовательного исполнения. Напротив, программа
представляет собой набор \term{обработчиков событий} -- объектов, часто
представляющих собой простые конечные автоматы. С каждым таким объектом
связан соответствующий модуль программы. В документации такой модуль
называется \term{callback}.

По мере возникновения внешних событий ядро системы -- \term{менеджер
событий} -- вызывает их обработчиков. При этом каждый обработчик вызывается
вполне синхронно, то есть менеджер передает управление и ждет, пока тот
его возвратит, как при обычном вызове процедуры в последовательной программе.
Поэтому, в соответствии с нашими определениями, менеджер событий вместе
с обработчиками является единственным в системе последовательный процессом,
который исполняется попеременно различными задачами. Подpобнее аpхитектуpа
\sysname{Windows} описана в \ref{EventSystems}.
}

Во многих операционных системах, например в \sysname{UNIX},
понятия задачи и процесса почти совпадают -- с каждым процессом
ассоциировано свое виртуальное адресное пространство. Новый процесс
формируется системным вызовом \verb"fork", который также формирует и
новое виртуальное адресное пространство.

{\small
Вообще, вызов \verb"fork" является достаточно любопытной
конструкцией. Этот вызов создает две задачи, которые в первый момент
полностью идентичны, у них различается только значение, возвращенное
вызовом \verb"fork". Типичная программа, использующая этот вызов,
выглядит так:
\begin{example}\nopagebreak
\small
\begin{verbatim}

    int pid; /* Идентификатор порожденного процесса */

    switch(pid = fork())
    {
        case 0: /* Порожденный процесс */
           ......
        break;
        case -1: /* Ошибка */
           perror("Cannot fork");
           exit(1);
        default: /* Родительский процесс */
           ......
        /* Здесь мы можем ссылаться на порожденный процесс,
         *  используя значение pid */
    }
\end{verbatim}
\end{example}

При этом каждый из процессов имеет свою копию всех локальных и статических
переменных. На процессорах со страничным диспетчером памяти
физического копирования не происходит. Изначально оба процесса используют
одни и те же страницы памяти, а дублируются только те из них, которые были
изменены.

При этом, если мы хотим запустить другую программу, то мы должны исполнить
системный вызов из семейства \verb"exec". Вызовы этого семейства различаются
только способом передачи параметров. Все они прекращают исполнение текущего
процесса и создают новый процесс/задачу с новым виртуальным адресным
пространством, но с тем же идентификатором процесса. При этом у нового
процесса будет тот же приоритет, будут открыты те же файлы (это
часто используется), и он унаследует ряд других важных характеристик,
поэтому часто говорят, даже в документации, что это тот же самый процесс.
Во всяком случае, после \verb"exec" формируется совершенно новая задача.
Поэтому запуск другой программы в \sysname{UNIX} выглядит примерно так:
\begin{example}\label{fork_exec}\nopagebreak
\small
\begin{verbatim}

  int pid; /* Идентификатор порожденного процесса */

  switch(pid = fork())
  {
     case 0: /* Порожденный процесс */
        dup2(1, open("ls.log", O_WRONLY | O_CREAT));
        /* Перенаправить открытый файл #1
         * (stdout) в файл ls.log */

        execl("/bin/sh", "sh", "-c", "ls", "-l", 0);

     /* Сюда мы попадаем только при ошибке! */
     /* fall through */
     case -1: /* Ошибка */
         perror("Cannot fork or exec");
         exit(1);
     default: /* Родительский процесс */
         ......
     /* Здесь мы можем ссылаться на порожденный
      * процесс, используя значение pid */
  }
\end{verbatim}
\end{example}

Программа в примере \ref{fork_exec} запускает командный интерпретатор
\verb"/bin/sh", известный как \progname{Bourne shell}, приказывает
ему исполнить команду \verb"ls -l" и перенаправляет стандартный вывод
этой команды в файл \verb"ls.log".

Техника программирования, основанная на \verb"fork/exec", несколько
менее красива, чем принятая в современных системах реального времени или
в языке \progname{Ada}, где новый процесс исполняет свою программу, а не ту же самую,
что и родительский. Кроме того, на системах без диспетчера памяти
\verb"fork" требует копирования адресных пространств, что приводит
к большим накладным расходам, да и просто не всегда возможно.

 Наиболее простым аргументом в пользу \verb"fork"
является то, что на основе \verb"fork" достаточно легко можно смоделировать
описанную выше функцию \verb"processCreate(void (*processBody)())",
а на основе \verb"processCreate" смоделировать \verb"fork" нельзя.
Такой аргумент звучит не очень серьезно, пока мы не вспомним, что на основе
этой техники написано довольно много простых и удобных прикладных и системных
программ, например, тот же \progname{Bourne shell}. Поэтому функция \verb"fork"
внесена в стандарт \standname{POSIX} и, вообще, охраняется законом и традициями.

Более важная причина, которая, по-видимому, и заставила отцов-основателей
\sysname{Unix} остановиться на \verb"fork/exec" вместо \verb"processCreate"
-- это\ellipsis количество параметров процедуры \verb"processCreate",
которое могло бы оказаться необходимым. Действительно, в промежутке
между вызовами \verb"fork" и \verb"exec" родительская программа может
настроить многие свойства порождаемой задачи. Каждому из настраиваемых
таким образом свойств соответствует параметр эквивалентной функции
\verb"processCreate". Давайте посмотрим на список настраиваемых
свойств:

\begin{itemize}
\item Открытые файлы. При исполнении системного вызова \verb"fork",
порожденный процесс наследует все дескрипторы файлов, открытых родителем.
При вызове \verb"exec" сохраняются все дескрипторы файлов, у которых не был
установлен флаг \verb"CLOSE_ON_EXEC". По умолчанию, этот флаг не
устанавливается.

Переназначение первых трех файловых дескрипторов ( \verb"0" - \verb"stdin",
\verb"1" - \verb"stdout", \verb"2" - \verb"stderr") широко используется
командными процессорами \sysname{Unix} и другими программами для
переназначения ввода/вывода и объединения процессов в конвейеры.

Наследование остальных дескрипторов используется реже, но такие
программы известны -- например, демон HTTP версии \entname{Netscape}.

\item Управляющий терминал и идентификаторы сессии и группы процессов.
Многие командные процессоры используют эти идентификаторы для управлении
заданиями.

\item \termin{Среда}{environment} -- список текстовых строк формата
\verb"NAME=VALUE". Программа может получить значение переменной
с заданным именем прямым поиском в этом списке или вызовом библиотечной
функции \verb"getenv". Некоторые из переменных среды оказывают влияние
на поведение всех программ; например, переменная \verb"TERM" обозначает
тип используемого терминала и используется многими программами,
особенно экранными редакторами, для настройки на этот терминал.
Другие переменные оказывают влияние только на некоторые программы:
так, например, переменная \verb"LIBPATH" указывает редактору связей
\verb"ld", в каких директориях искать объектные библиотеки.

Пользователи \sysname{MS/DR~DOS} и \sysname{OS/2} должны быть знакомы с
переменными среды.

По умолчанию, все переменные среды родительской задачи наследуются
порожденной. Однако существуют два способа, которым родитель может
изменить среду новой задачи. Во-первых, некоторые формы вызова \verb"exec"
получают в качестве параметра новый список переменных среды.
Во-вторых, порожденный процесс перед вызовом \verb"exec" может сделать
один или несколько вызовов функции \verb"putenv", или модифицировать
свою среду <<вручную". При этом все изменения автоматически унаследуются
порожденной задачей, а среда родительской задачи не изменится.

\item Сигнальная маска. Задача может игнорировать отдельные сигналы,
задерживать их обработку или устанавливать функцию-обработчик.
Операции игнорирования и задержки определяются сигнальной маской.
При \verb"fork" сигнальная маска и обработчики наследуются;
при \verb"exec" сигнальная маска наследуется, а обработчики сбрасываются:
ведь в адресном пространстве новой задачи уже не будет кода обработчиков.

\item Текущая директория.

\item Маска прав доступа \verb"umask". Права доступа к файлам в
\sysname{Unix} задаются девятибитовой маской: права чтения, записи и
исполнения для хозяина файла, группы и всех остальных. При создании
файла программа задает права доступа к нему. Заданная маска прав
объединяется логическим И с обращенным значением \verb"umask".
Эта, на первый взгляд немного странная, процедура предоставляет относительно
удобный способ управления правами доступа к вновь создаваемым файлам.
\end{itemize}

Эти параметры изменяются почти при каждом вызове
\verb"fork/exec". Параметры, перечисленные ниже, изменяют не так часто,
но они оказывают серьезное воздействие на исполнение порожденной
задачи, и нередко бывает {\it необходимо} настроить их.

\begin{itemize}
\item Приоритет процесса.

\item Корневая директория. Обычно она совпадает с корневой директорией
файловой системы, но \sysname{Unix} позволяет переместить корневую
директорию текущей задачи. Тогда задача будет видеть только поддерево
общего дерева директорий. Это часто используется при создании <<гостевых"
входов в систему с сильно ограниченными правами.

\item \verb"ulimit" -- максимальная длина файла, который может быть создан
задачей. Этот параметр бывает полезен при отладке.

\item Ряд других ограничительных параметров, например максимальный размер
адресного пространства новой задачи.
\end{itemize}

Итак, мы получили более десяти параметров, которые следовало бы передать
функции \verb"processCreate", не считая имени запускаемой программы
и позиционных аргументов (\verb"argc/argv"). Необходимо также учесть,
что многие аргументы представляют собой не скалярные значения, а массивы,
каждый элемент которых также нуждается в настройке.

В свете сказанного преимущество \verb"fork/exec" перед \verb"processCreate"
представляется очевидным.
}

В соответствии с нашим определением, каждая задача имеет собственный
сегмент данных. Поэтому для организации взаимодействия между задачами
необходимы отдельные средства.

\section{Разделяемая память}

Самым простым из таких средств может быть организация сегмента памяти,
разделяемого между задачами. В системах с виртуальной памятью такой сегмент
организуется просто -- мы отображаем одни и те же физические страницы
на адресные пространства различных задач -- и получаем разделяемый
сегмент.

Самое интересное состоит в том, что можно организовать
разделяемую память и для задач, исполняющихся на различных машинах.
Для этого необходим блок двухпортовой памяти, подключенный к системным шинам
обеих машин. Такое решение часто используется в многопроцессорных
системах, особенно когда нам нужно организовать быстрый обмен большими
(десятки мегабайт) объемами данных. Например, по такой схеме организован
обмен между основным(и) процессорами и видеопроцессором в графических
станциях \machname{Silicon Graphics}.

Можно создать разделяемую между машинами память и в том случае, если
машины не имеют физической общей памяти. Для этого необходимо использовать
диспетчер памяти. Реализация относительно проста: диспетчер
памяти отслеживает все записи в <<разделяемый>> сегмент, а затем системы
тем или иным способом обеспечивают синхронизацию содержимого измененных
сегментов. Беда только в том, что этот метод требует относительно больших
накладных расходов.

Теоретики не очень любят разделение памяти, потому что оно влечет
за собой все проблемы, перечисленные в предыдущем разделе: необходимость
синхронизации, критические секции и т.д. На практике, однако, оно
часто оказывается необходимым, так как обеспечивает наибольшую скорость
обмена данными -- до сотни мегабайт в секунду для современных компьютеров.
Тем не менее,  используя разделяемую память, мы должны также использовать
для синхронизации какие-либо другие средства. В \sysname{OS/2},
\sysname{Windows~NT} и системах типа \sysname{VxVorks} чаще всего
используются семафоры.

\section[Гармоническое взаимодействие]{Средства для
гармонического межпроцессного взаимодействия}

Ряд систем предоставляет более простые в использовании средства,
предоставляющие обмен данных одновременно с синхронизацией. Одним
из наиболее типичных средств такого рода является \termin{труба}{pipe}
или \term{программный канал} -- основное средство взаимодействия
между процессами в ОС семейства \sysname{Unix}.

\subsection{Трубы (програмные каналы)}

Труба представляет собой поток байтов. С одного конца в этот поток
можно записывать данные, из другого -- считывать. Процесс, который пытается
считать данные из пустой трубы, будет задержан, пока там не появятся данные.
Напротив, пишущий процесс может записать в трубу некоторое количество данных,
прежде чем труба заполнится и дальнейшая запись будет заблокирована.
На практике труба реализована в виде небольшого (несколько килобайт)
кольцевого буфера. Пишущий процесс заполняет этот буфер, пока там есть место.
Читающий процесс считывает данные, пока буфер не опустеет.

Читающий процесс может проверить наличие данных в трубе и
предпринять какие-то действия в случае их отсутствия.
Пишущий процесс также может проверять трубу на переполнение.

По-видимому, трубы являются одной из первых техник,
реализующих гармонически взаимодействующие процессы по Дийкстре.

Самым интересным свойством трубы является то, что чтение данных
из трубы и запись в нее осуществляется теми же самыми системными вызовами
\verb"read" и \verb"write", что и работа с обычным файлом или внешним
устройством типа терминала. На этом основана техника переназначения
ввода-вывода, широко используемая в командных интерпретаторах \sysname{UNIX}.
Эта техника состоит в том, что большинство системных утилит получают
данные из потока стандартного ввода (\verb"stdin") и выдают их в поток
стандартного вывода (\verb"stdout"). При этом, подсовывая в качестве
этих потоков терминальное устройство, файл или трубу, мы можем использовать
в качестве ввода, соответственно: текст, набираемый с клавиатуры,
содержимое файла или стандартный вывод другой программы. Аналогично
мы можем выдавать данные сразу на экран, в файл или передавать их на
вход другой программы.

{\smallТак, например, компилятор \progname{GNU C} состоит из трех основных
проходов: препроцессора, собственно компилятора, генерирующего текст
на ассемблере, и ассемблера. При этом внутри компилятора, на самом деле,
также выполняется несколько проходов по тексту (в описании перечислено
{\bf восемнадцать}), в основном для оптимизации, но нас это в данный
момент не интересует, поскольку все они выполняются внутри одной задачи.
При этом все три задачи объединяются трубами в единую линию
обработки входного текста -- \termin{конвейер}{pipeline}.
При этом любая из программ может также брать входные данные из файла.
}

Трубы широко используются системами семейства \sysname{Unix} и они внесены
в стандарт \standname{POSIX}. Ряд операционных систем, не входящих в семейство
\sysname{Unix}, например \sysname{VxWorks}, также предоставляют
этот сервис.

Система \sysname{VMS} предоставляет средства, отчасти аналогичные
трубам, называемые {\it почтовые ящики (mailbox}). Почтовый ящик
также представляет собой кольцевой буфер, доступ к которому осуществляется
теми же системными вызовами, что и работа с внешним устройством.
Системная библиотека языка VAX C использует почтовые ящики для реализации
труб, в основном совместимые с \sysname{UNIX} и стандартом \standname{POSIX}.

{\small
В системе \sysname{UNIX} труба создается системным вызовом
\verb"pipe(int fildes[2])". Этот вызов создает трубу и помещает
дескрипторы файлов, соответствующие входному и выходному концам трубы,
в массив \verb"fildes". Затем мы можем выполнить \verb"fork", в различных
процессах переназначить соответствующие концы трубы на место \verb"stdin"
и \verb"stdout" и запустить требуемые программы. При этом мы получим
типичный конвейер -- две задачи, стандартный ввод и вывод которых соединены
трубой.

Можно понять, что такие трубы можно использовать только для связи
родственных задач, т.е. таких, которые связаны отношением родитель-потомок
или являются потомками одного процесса.

Для связи между неродственными задачами используется другое средство --
\termin{именованные трубы}{named pipes} в \sysname{System V} и
\term{UNIX domain sockets} в \sysname{BSD UNIX}. В разных
системах именованные трубы создаются различными системными вызовами,
но очень похожи по свойствам.
Поэтому стандарт \standname{POSIX} предлагает для создания именованных труб
библиотечную функцию \verb"mkfifo(const char * name, mode_t flags);".
Эта функция создает специальный файл. Открывая такой файл, программа
получает доступ к одному из концов трубы. Когда две программы откроют
именованную трубу, они смогут использовать ее для обмена данными точно
так же, как и обычную.
}

\subsection{Линки}

\label{transputerLinks}
В транспьютерах микропрограммно реализован \termint{линки}{links}{связь}:
механизм, отчасти похожий на трубы.

Линки бывают двух типов -- физические и логические. Операции над линками
обоих типов осуществляются одними и теми же командами.

Физический линк представляет собой последовательный интерфейс
\protname{RS432}, реализованный на кристалле процессора. С линком также
ассоциировано одно слово памяти, смысл которого будет объяснен ниже.

Современные
транспьютеры имеют четыре физических линка. Физические линки могут передавать
данные со скоростью до 20 Mbaud и могут использоваться как для соединения
транспьютеров между собой, так и для подключения внешних устройств.
Поэтому физический линк может использоваться как для связи между процессами
на разных транспьютерах, так и для синхронизации процесса с внешними
событиями, и даже просто для ввода/вывода.

Логический линк -- это просто структура данных, выделенная в физическом
адресном пространстве процессора. С точки зрения программы физический
и логический линки ничем не отличаются, кроме того, что описатель
физического линка привязан к определенному физическому адресу.
Логический линк может использоваться только для связи между процессами,
исполняющимися на одном транспьютере.

Транспьютер \sysname{T9000} предоставляет также виртуальные линки --
протокол, позволяющий двум транспьютерам организовать несколько линий
взаимодействия через один физический линк, или даже через цепочку
маршрутизаторов.

\note{Как уже говорилось, процессы взаимодействуют через физические, логические
и виртуальные линки совершенно одинаково. Поэтому мы можем отладить
параллельную программу в однопроцессорной системе, а потом запустить ее в
гиперкубе из 64К транспьютеров -- и она будет вести себя точно также, только
начнет работать в 64К раз быстрее.
}

При передаче данных в линк, процесс должен исполнить команду \verb"out".
Эта команда имеет три операнда: адрес линка, адрес массива данных и
количество данных. Для передачи операндов используется регистровый стек
процессора, но это несущественно. Процесс, исполнивший такую команду,
задерживается до тех пор, пока все данные не будут переданы.

Аналогично, при приеме данных из линка, процесс должен исполнить команду
\verb"in". Эта команда также имеет три операнда -- адрес линка, адрес
буфера, куда необходимо поместить данные и размер буфера. При исполнении
такой команды процесс блокируется до тех пор, пока буфер не будет заполнен
данными. При этом приемник и передатчик могут использовать буфера разного
размера, т.е. приемник может считывать большой массив данных в несколько
приемов и т.д.

Существует также команда \verb"alt", позволяющая процессу ожидать данных
из нескольких линков одновременно. В качестве одного из ожидаемых
событий можно также использовать сигнал от системного таймера.

Слово, связанное с линком, содержит указатель на дескриптор процесса,
ожидающего на линке. Кpоме того, это слово может пpинимать значение
\verb"NotProcessP", указывающее, что линка никто не ждет.
Остальная инфоpмация, такая, как указатель на буфер
и pазмер буфера, хpанится в дескpиптоpе пpоцесса.

Hапpавление пеpедачи данных опpеделяется командой, котоpую исполнит
очеpедной пpоцесс пpи обpащении к этому линку. Hапpимеp, если
исполняется команда \verb"out", предназначенные к записи данные
копируются в буфер ожидающего пpоцесса. При этом указатель буфера
продвигается, а счетчик размера уменьшается на количество скопированных данных.
Если же в линке записано значение \verb"NotProcessP", пpоцесс пеpеводится
в состояние ожидания и указатель на его дескpиптоp помещается в линк.

Аналогично обрабатываются запросы на чтение. Если мы имеем более двух
пpоцессов, пытающихся использовать один линк, то возникает сеpьезная пpоблема:
внимательный читатель должен был заметить, что мы не сказали, где
хpанится инфоpмация о том, чего ожидает текущий пpоцесс: чтения или записи.
Пpоблема состоит в том, что эта инфоpмация {\it нигде} не хpанится.
Если пpоцесс попытается записать данные в линк, на котоpом кто-то уже
ожидает записи, то данные втоpого пpоцесса будут записаны повеpх данных
ожидавшего. Если pазмеpы буфеpов совпадут, то ожидавший пpоцесс будет
пpебывать в убеждении, что он успешно пеpедал все данные.
Поэтому линки pекомендуется использовать только для однонапpавленной
пеpедачи данных между двумя (не более!) пpоцессами.

При работе с физическим линком данные не копируются, а передаются или
принимаются через физический канал в режиме прямого доступа к памяти.

В отличие от труб, линк не содержит внутреннего буфера. Это означает,
что передающий процесс по окончании передачи может быть уверен, что данные
получены (если не пpоизошло описанного выше конфликта). Поэтому линки можно
использовать как средство синхронизации двух процессов.
Трубы для этого непригодны именно из-за наличия буфера.
С другой стороны, по линку нельзя передавать данные по принципу
<<выстрелил и забыл>>, как это часто делают с трубами.

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

\note{Интересно, что в версиях ОС \sysname{Unix}, основанных на микроядре,
трубы реализованы именно таким образом: микроядро предоставляет
низкоуровневые операции \verb"send" и \verb"receive", функционально очень
похожие на команды \verb"in" и \verb"out" транспьютера. Системные вызовы
\verb"read" и \verb"write" представляют собой относительно высокоуровневый
интерфейс к командам микроядра. Эти вызовы обмениваются данными через
буферный процесс, создаваемый в ядре системы при инициализации трубы.
}

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

\section{Системы, управляемые событиями}\label{EventSystems}

В начале 70-х годов появилась новая архитектура многозадачных систем,
довольно резко отличающаяся от вышеописанной модели последовательных
процессов. Речь идет о так называемых
\termin{системах, управляемых событиями}{event-driven systems}.

Впервые эта архитектура была реализована в экспериментальных настольных
компьютерах \machname{Alto}, разработанных в 1973 году в исследовательском
центре \entname{PARC} фирмы \entname{Xerox}. Целью эксперимента было создание
операционной среды, удобной для создания интерактивных программ.

В этих системах впервые была реализована многооконная графика, когда
пользователь одновременно видит на экране графический вывод нескольких
программ и может активизировать любую из них, указав на соответствующее
окно при помощи манипулятора-<<мыши>>.

При каждом движении мыши, нажатии на ее кнопки или клавиши на клавиатуре
генерируется \term{событие}. События могут также генерироваться
системным таймером или пользовательскими программами. Существуют также
так называемые <<визуальные>> события: например, сдвинув или закрыв одно
из окон, мы открыли часть окна, находившегося внизу. Этому окну посылается
событие, говорящее о том, что ему нужно перерисовать часть себя.

Каждое событие представляет собой структуру данных, которая содержит
код, обозначающий тип события:
движение мыши, нажатие кнопки и т.д., а также поля, различные для
различных типов событий: для <<мышиных>> событий это текущие
координаты мыши и битовая маска, обозначающая состояние кнопок
(нажата/отпущена). Для клавиатурных событий это код нажатой клавиши --
обычно, ASCII для алфавитно-цифровой клавиатуры и специальные коды для
стрелок и других <<расширенных>> клавиш -- и битовая маска, обозначающая
состояние различных модификаторов, таких как \verb"SHIFT, CNTRL, ALT" и т.д.;
для визуальных событий это координаты прямоугольника, который нужно
перерисовать, и так далее.

Все события помещаются в очередь в порядке их возникновения.

В системе существует понятие \term{обработчика событий}. Обработчик событий
представляет собой объект, то есть структуру данных, с которой связано
несколько программных модулей -- \term{методов}. Один из методов вызывается
при поступлении события и называется \termin{callback}{дословно -- <<вызов
назад>>}.

Представим себе простой объект, такой как меню. При нажатии на кнопку
мыши в области этого меню вызывается callback. Он разбирается,
какой из пунктов меню был выбран, и вызывает соответствующую функцию
обработки этого пункта. Таким образом, вместо последовательно исполняющейся
программы, время от времени вызывающей систему для исполнения той или иной
функции, мы получаем набор callback'ов, вызываемых системой в соответствии
с желаниями пользователя. Отсюда, видимо, и происходит термин
<<callback>> -- это <<системный вызов, идущий в обратном направлении>>.

Специальная программа, \term{менеджер событий}, непрерывно просматривает
очередь и передает поступающие события обработчикам. События, связанные
с экранными координатами, передаются обработчику, ассоциированному с
соответствующим окном. Клавиатурные события передаются
\term{фокусу клавиатуры} -- текущему активному обработчику.

% подробнее описать

Легко понять, что менеджер и обработчики событий достаточно
органично вписываются в традиционную многозадачную ОС.
События становятся дополнительным средством синхронизации
и передачи данных, удобным для организации пользовательского
интерфейса. В других ситуациях программист может пользоваться другими
средствами.
Так устроены \sysname{Windows~NT} и оконная подсистема \sysname{OS/2} --
\progname{Presentation Manager}.
Особенно любопытен в этом отношении опыт сетевой оконной системы
X Windows, где передача событий реализована на основе стандартных
средств межпроцессного взаимодействия: труб или разделяемой памяти
при работе в пределах одной машины и \term{сокетов}\footnote{Средство
сетевого обмена данными, во многом похожее на трубы.}
при взаимодействии с удаленной машиной.

Однако наиболее распространенные в настоящее время событийные системы:
\sysname{MS~Windows~3.x} и \sysname{MacOS} реализуют иной подход.

Эти системы, занимающие промежуточное положение между ОС и ДОС,
реализуют кооперативную многозадачность. В большинстве же случаев
даже кооперативная многопроцессность не используется: менеджер событий
синхронно вызывает callback'и, и все программы работают как единый процесс.
Предполагается, что обычно callback исполняется быстро, а возможность
переключать фокус между различными задачами дает пользователю многие
из преимуществ многопроцессной системы. Если долго исполняющиеся callback'и
регулярно вызывают функцию \verb"GetNextEvent", то можно создать довольно
приличную иллюзию полноценной ОС.

Одним из основных недостатков такой архитектуры является то, что система
оказывается зависимой от качества реализации приложений: чем реже
приложение вызывает \verb"GetNextEvent", тем менее работа системы похожа на
многопроцессную. Другие недостатки кооперативной многопроцессности
обсуждались в разделе \ref{CoopMT}.
Кроме того, кооперативное переключение процессов существенно  усложняет
реализацию сетевых приложений и \term{multimedia}: чувствительные к времени
реакции программы не могут исполняться как обычные задачи, они вынуждены
отбирать управление у системы.

В \sysname{Windows~3.x} для этой цели предоставляется возможность
регистрировать так называемые \progname{VxD} --  модули, исполняющиеся
с привилегиями ядра системы. Такие модули могут непосредственно
обрабатывать внешние события и реагировать на них, не отдавая управления
ядру. В \sysname{Windows~3.x} и \sysname{Windows~95} \progname{VxD}
являются единственным средством, пригодным для реализации приложений,
нуждающихся в жесткой синхронизации,
например, для синхронизации звука и изображения в multimedia.

{\small
Это техническое решение очень характерно для фирмы \entname{MicroSoft}:
вместо полноценной реализации той или иной функции предоставлять
разработчикам приложений недокументированные <<задние двери>>.
Занятно, что большинство таких задних дверей так или иначе относятся
к многопроцессности, синхронизации и межпроцессному взаимодействию.

Так, вместо защиты ядра \sysname{MS~DOS} от повторных вызовов и
нормального сервиса для обработки прерываний, \entname{MicroSoft}
реализовал недокументированный флаг занятости ДОС.

Вместо вытесняющей многопроцессности в \sysname{Windows~3.x}
предоставлен системный вызов \verb"getNextEvent"

Вместо полноценных средств синхронизации и быстрой реакции на события
в \sysname{Windows~3.x} предоставлены \progname{VxD}, то есть
возможность искажения работы ядра системы.
}

Самым интересным во всем этом является тот печальный факт, что
программы, использующие \progname{VxD}, не могут исполняться
в ОС \sysname{Windows~NT}, которую \entname{MicroSoft} рекламирует
в качестве <<системы будущего>>\ellipsis
