Что такое процесс? В исходной реализации Unix процессом была любая выполняющаяся программа. Для каждой программы ядро системы отслеживает перечисленные ниже аспекты.

• Текущая точка выполнения (такая как ожидание возврата системного вызова из ядра), часто называемая программным контекстом.

• К каким файлам имеет доступ программа.

• Сертификаты (credentials) программы (например, какой пользователь и группа владеют процессом).

• Текущий каталог программы.

• К какому пространству памяти имеет доступ программа и как оно распределено.

Процесс также является базовой единицей планирования для операционной системы. Только процессам разрешено выполняться в центральном процессоре.

 

10.1.1. Усложнение концепции — потоки

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

Многие реализации Unix (включая каноническую версию AT&T System V) были перепроектированы, чтобы сделать потоки фундаментальным элементом планирования для ядра, и процесс превратился в коллекцию потоков, разделяющих ресурсы. Поскольку множество ресурсов разделяется между потоками, ядро может быстрее переключаться между потоками одного процесса, чем оно это делает при полноконтекстном переключении между процессами. В результате в большинстве ядер Unix существует двухуровневая модель процессов, которая различает потоки и процессы.

 

10.1.2. Подход Linux

В Linux, однако, все идет другим путем. Переключение контекстов в Linux всегда было исключительно быстрым (примерно на том же уровне, как новые "переключатели потоков", представленные в двухуровневом подходе), что стимулировало разработчиков ядра вместо смены подхода к планированию процессов позволить процессам разделять ресурсы более либерально.

Под Linux процесс определен исключительно как планируемая сущность, и единственная вещь, которая уникальна для процесса — это текущий контекст выполнения. Он не предполагает ничего относительно разделенных ресурсов, потому что процесс, создающий новый дочерний процесс, имеет полный контроль над тем, какие из ресурсов процессы могут разделять между собой (см. детали в описании системного вызова clone() в конце этой главы). Эта модель позволяет сохранять традиционную систему управления процессами Unix, в то время как традиционный интерфейс потоков строится вне ядра.

К счастью, разница между моделью процессов Linux и двухуровневым подходом проявляется редко. В настоящей книге мы используем термин процесс для обозначения набора из (обычно, одной) планируемых сущностей, которые разделяют основные ресурсы. Когда процесс состоит из одного потока, мы используем эти термины как взаимозаменяемые. Чтобы не усложнять, в большей части этой главы мы будем игнорировать потоки полностью. До ее завершения мы обсудим системный вызов clone(), который используется для создания потоков (и может также создавать нормальные процессы).

 

10.2.1. Идентификатор процесса и происхождение

Два из наиболее фундаментальных атрибутов — это идентификатор процесса (process ID), или pid, а также идентификатор его родительского процесса. Идентификатор pid — это положительное целое число, которое уникально идентифицирует работающий процесс и сохраняется в переменной типа pid_t. Когда создается новый процесс, исходный процесс, известный как родитель нового процесса, будет уведомляться, когда этот дочерний процесс будет завершен.

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

Если родитель процесса завершается (делая дочерний процесс висячим), такой процесс становится дочерним для начального процесса (init). Начальный процесс — это первый процесс, который запускается при загрузке машины и которому присваивается значение pid, равное 1. Одной из основных задач начального процесса является сбор кодов завершения процессов, чьи родители исчезли, позволяя ядру удалять такие дочерние процессы из таблицы процессов системы. Процессы могут получать свой pid и pid родителя с помощью функций getpid() и getppid().

 

10.2.2. Сертификаты

В Linux используются традиционные механизмы обеспечения безопасности Unix для пользователей и групп. Идентификаторы пользователя (uid) и группы (gid) — это целые числа, которые отображаются на символические имена пользователей и групп в файлах /etc/passwd и /etc/group, соответственно (более подробную информацию о базах данных пользователей и групп можно получить в главе 28). Однако ядро ничего не знает об именах — оно имеет дело только с целочисленными представлениями. Идентификатор uid, равный 0, зарезервирован за системным администратором, обычно имеющим имя root. Все обычные проверки безопасности отключаются для процессов, запущенных от имени root (то есть с uid, равным 0), что дает администратору полный контроль над системой.

В большинстве случаев процесс имеет единственный uid и единственный gid, ассоциированный с ним. Это идентификаторы, которые используются для большинства целей обеспечения безопасности (как, например, назначение прав владения вновь созданным файлам). Системные вызовы, которые могут модифицировать принадлежность процессов, обсуждаются далее в настоящей главе.

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

Дополнительные группы были представлены в BSD 4.3 для решения этой проблемы. Хотя каждый процесс по-прежнему имеет собственный первичный gid (который используется, например, как gid для вновь создаваемых файлов), он также связан с набором дополнительных групп. Проверки безопасности, которые используются для обеспечения того, что процесс относится к определенной группе (и только этой группе), теперь позволяет обеспечить доступ и в случае, когда данная группа является одной из дополнительных групп, к которым процесс относится. Макрос sysconf() по имени _SC_NGROUPS_МАХ специфицирует, к скольким дополнительным группам может относиться процесс. (Подробно о sysconf() см. главу 6.) В Linux 2.4 и более ранних версиях _SC_NGROUPS_MAX был равен 32. В Linux 2.6 и последующих версиях _SC_NGROUPS_MAX равен 65536. Не используйте статические массивы для хранения дополнительных групп. Вместо этого выделяйте память динамически, принимая во внимания значение, возвращаемое sysconf(_SC_NGROUPS_MAX). Старый код может пользоваться макросом NGROUPS_MAX для определения количества поддерживаемых групп, установленных в системе. Этот макрос не обеспечивает корректную работу, когда код компилируется в одной среде, а используется в другой.

Установка списка групп для процесса осуществляется системным вызовом setgroups() и может быть выполнена процессом, имеющим полномочия root.

int setgroups(size_t num, const gid_t * list);

Параметр list указывает на массив из num идентификаторов групп gid. Дополнительная группа процесса устанавливается этим списком идентификаторов групп, переданным в массиве list.

Функция getgroups() позволяет получить список дополнительных групп, установленных для процесса.

int getgroups(size_t num, gid_t * list);

list должен указывать на массив элементов типа gid_t, который наполняется идентификаторами дополнительной группы процесса, a num определяет, сколько элементов может типа gid_t содержать list. В случае ошибки системный вызов getgroups() возвращает -1 (обычно это происходит, когда list недостаточно велик, чтобы вместить дополнительный список групп процесса), или же количество дополнительных групп. В особом случае, когда num равно 0, getgroups() просто возвращает количество дополнительных групп процесса.

Ниже показан пример использования getgroups().

gid_t *groupList;

int numGroups;

numGroups = getgroups(0, groupList);

if (numGroups) {

 groupList = alloca(numGroups * sizeof(gid_t));

 getgroups(numGroups, groupList);

}

Более сложный пример getgroups() приведен в главе 28.

Таким образом, процесс имеет uid, первичный gid и набор дополнительных групп, ассоциированных с ним. К счастью, это все, о чем нужно знать большинству программистов. Существуют два класса программ, которым необходимо очень гибкое управление идентификаторами пользователей и групп — это программы setuid/setgid и системные демоны.

Системные демоны — это программы, которые всегда запущены в системе и выполняют определенные действия в ответ на внешние воздействия. Например, большинство демонов World Wide Web (http) функционируют всегда, ожидая подключения к ним клиента, чтобы обрабатывать клиентские запросы. Другие демоны, такие как cron (которые запускаются периодически), пребывают в спящем состоянии до тех пор, пока не наступает время, когда они должны выполнить какие-то действия. Большинство демонов должны быть запущены с полномочиями root, но выполняют действия по запросу пользователя, который может попытаться нарушить системную безопасность с помощью демонов.

ftp — хороший пример демона, который нуждается в гибком управлении uid. Изначально он запускается с правами root и затем переключает свой uid на uid пользователя, который подключился к нему (большинство систем запускают дополнительный процесс для обработки каждого ftp-запроса, поэтому такой подход работает достаточно хорошо). Это оставляет работу по проверке доступа к файлам ядру, к которому он относится. Однако в некоторых случаях демон ftp должен открывать сетевое подключение таким способом, который разрешен только root, поскольку пользовательские процессы не могут выдать сами себе административные полномочия (по вполне ясной причине), но сохранение идентификатора uid пользователя root вместо переключения на пользовательский uid должен потребовать от демона ftp самостоятельной проверки всего доступа к файловой системе. Решение этой дилеммы применяется симметрично — к обоим uid и первичным gid, поэтому мы и говорим здесь об uid.

В действительности процесс имеет три uid: реальный, сохраненный и эффективный uid. Эффективный uid используется для всех проверок безопасности и является единственным uid процесса, который обычно имеет какой-то эффект.

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

Обычно эффективный, реальный и действительный uid процесса совпадают. Однако этот механизм решает дилемму демона ftp. Когда он запускается, все его идентификаторы устанавливаются в 0, что предоставляет ему полномочия root. Когда подключается пользователь, демон устанавливает свой эффективный uid равным uid пользователя, оставляя сохраненный и действительный uid равными 0. Когда демону ftp требуется выполнить действие, разрешенное только root, он устанавливает свой эффективный uid в 0, выполняет действие, а затем переустанавливает эффективный uid в значение uid подключенного пользователя.

Хотя демон ftp вообще не нуждается в сохраненном uid, другие классы программ, применяющие этот механизм — двоичные модули setuid и setgid — используют его.

Программа passwd — это простой пример того, зачем нужна функциональность setuid и setgid. Программа passwd позволяет пользователям изменять свои пароли. Пользовательские пароли обычно хранятся в файле /etc/passwd. Выполнять запись в этот файл может только пользователь root, что предотвращает изменение информации о пользователях другими пользователями. Но пользователи должны иметь возможность изменять свои собственные пароли, поэтому необходим какой-то способ предоставить программе passwd права на изменение /etc/passwd.

Чтобы обеспечить эту гибкость, пользователь программы может устанавливать специальные биты в группе бит прав доступа этой программы (см. главу 11). Это сообщает ядру, что всякий раз, когда программа запускается, она должна выполняться с тем же эффективным uid (или gid), как у пользователя, который владеет файлом программы, независимо от того, какой пользователь запустил программу. Такие программы называются setuid- или setgid-программами.

Принадлежность программы passwd пользователю root и установка бита setuid в наборе битов доступа программы позволяют всем пользователям изменять свои пароли. Когда пользователь запускает passwd, эта программа выполняется с эффективным идентификатором пользователя 0, что позволяет ей модифицировать /etc/passwd и изменять пользовательский пароль. Конечно, passwd должна быть реализована очень тщательно, дабы исключить побочные эффекты. Программы setuid — это популярная цель для злоумышленников, проникающих в систему, поэтому плохо написанная программа подобного рода дает простую возможность получить неавторизованный доступ.

Существуют много случаев, когда программы setuid требуют специальных прав доступа на короткий период времени и должны переключаться на uid действительного пользователя в остальное время (как это делает демон ftp). Программы setuid имеют установленный эффективный uid равным uid ее владельца, но они также "знают" uid того пользователя, который их запустил (сохраненный uid), что упрощает обратное переключение. В дополнение они могут устанавливать свой действительный uid в значение setuid (не затрагивая сохраненный uid), при необходимости повторно получая эти специальные полномочия. В этой ситуации эффективный, сохраненный и действительный идентификаторы пользователя работают вместе, насколько возможно, упрощая систему безопасности.

К несчастью, применение этого механизма может сбивать с толку, поскольку в POSIX и BSD применяются слегка отличающиеся подходы, a Linux поддерживает оба. Решение BSD более полнофункционально, чем метод POSIX. Оно использует функцию setreuid().

int setreuid(uid_t ruid, uid_t euid);

Действительный uid процесса устанавливается в ruid, а эффективный — в euid. Если любой из параметров равен -1, идентификатор вызовом не затрагивается.

Если эффективный uid процесса равен 0, такой вызов всегда выполняется успешно. В противном случае идентификаторы могут быть установлены равными либо сохраненному uid, либо реальному uid процесса. Следует отметить, что этот вызов никогда не изменяет сохраненный uid или реальный uid текущего процесса. Чтобы сделать это, используйте функцию POSIX setuid(), которая может модифицировать сохраненный uid.

int setuid(uid_t euid);

Как и в случае setreuid() эффективный uid процесса устанавливается в euid, если euid равен действительному uid процесса либо эффективный uid процесса на момент вызова равен 0.

Когда setuid() используется процессом, чей эффективный uid установлен в 0, все uid процесса изменяются на euid. К сожалению, это делает невозможным использование setreuid() в setuid-программах, которым нужно временное использование другого uid, поскольку после вызова setreuid() процесс не может восстановить свои полномочия root.

Хотя способность переключать uid упрощает написание кода, с помощью которого нельзя нарушить безопасность системы, все же это не панацея. Существует очень много популярных методов обманного проникновения в выполняющийся код [18]. До тех пор пока либо сохраненный, либо действительный uid процесса равен 0, такие атаки легко могут устанавливать эффективный uid процесса в 0. Это не дает возможности переключению uid эффективно предотвращать серьезную уязвимость системных программ. Однако если процесс может передать любой доступ к полномочиям root, устанавливая эффективный, сохраненный и действительный идентификаторы в ненулевые значения, это ограничивает эффективность любых атак против него.

 

10.2.3. Идентификатор uid файловой системы

В очень специальных случаях программе может понадобиться сохранять свои права root для всего, кроме доступа к файловой системе, при котором она использует пользовательский uid. Изначально использовавшийся в Linux NFS-сервер пространства пользователя может служить иллюстрацией проблемы, которая возникает, когда процесс предполагает применение пользовательского uid. Хотя NFS-сервер в прошлом применял setreuid() для переключения uid при доступе к файловой системе, такое поведение позволяло пользователю, чей uid совпадает с uid NFS-сервера, уничтожать NFS-сервер. В конечном итоге, пользователь получал владение процессом NFS-сервера. Чтобы предотвратить проблемы подобного рода, Linux использует uid файловой системы (fsuid) для контроля доступа к файловой системе.

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

int setfsuid(uid_t uid);

Значение fsuid может быть установлено равным текущим эффективному, сохраненному или действительному идентификаторам пользователя. В дополнение следует сказать, что setfsuid() выполняется успешно, если fsuid остается неизменным или эффективный uid процесса равен 0.

 

10.2.4. Резюме по идентификаторам пользователей и групп

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

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

 

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

 

10.3.1. Аргументы программы

Есть два типа значений, передаваемых новым программам при их запуске: аргументы командной строки и переменные окружения. Для их использования установлено множество соглашений, но система сама по себе не придерживается их автоматически. Однако хорошим тоном считается придерживаться этих соглашений, чтобы помочь вашим программам попасть в мир Unix.

Аргументы командной строки — это набор строк, передаваемый программе. Обычно они представляют собой текст, набранный вслед за именем команды в оболочке, с необязательными аргументами, начинающимися с символа "минус" (-).

Переменные окружения — это набор пар "имя-значение". Каждая пара представляет отдельную строку в форме ИМЯ = ЗНАЧЕНИЕ , и набор таких строк образует окружение (environment) программы. Например, домашний каталог текущего пользователя обычно указан в переменной окружения HOME, поэтому программы, скажем, пользователя Joe часто запускаются, имея в своем окружении HOME=/home/joe.

И аргументы, и окружение становятся доступными программе при запуске. Аргументы командной строки передаются в виде параметров главной функции программы — main(), в то время как указатель на окружение помещается в глобальную переменную environ, которая определена в .

Ниже представлен полный прототип функции main() в мире Linux, Unix и языка ANSI/ISO С.

int main(int argc, char *argv[]);

Возможно, вас удивит, что main() возвращает значение (отличное от void). Это значение, возвращаемое функцией main(), передается родительскому процессу после завершения данного. По соглашению 0 означает, что процесс завершен успешно, а ненулевое значение означает возникновение сбоя. При этом принимаются во внимание только младшие 8 бит из этого кода возврата. Отрицательные значения от -1 до -128 зарезервированы для ненормального завершения процессов по инициативе другого процесса или ядра системы. Код выхода 0 сигнализирует об успешном завершении, а значения от 1 до 127 говорят о том, что программа завершена по ошибке.

Первый параметр, argc, содержит количество аргументов командной строки, переданных программе, тогда как argv — массив указателей на строки — хранит сами аргументы. Первый элемент в массиве, argv[0], содержит имя вызванной программы (хотя и не обязательно полный путь к ней). В элементе argv[argc-1] расположен указатель на завершающий аргумент командной строки, а argv[argc] содержит NULL.

Чтобы получить прямой доступ к окружению, используйте следующую глобальную переменную:

extern char *environ[];

Это представляет environ как массив указателей на каждый элемент программного окружения (помните, каждый элемент — это пара ИМЯ = ЗНАЧЕНИЕ ), и финальный элемент массива содержит NULL. Это объявление находится в , поэтому вам не обязательно объявлять его самостоятельно.

Наиболее общий способ проверки элементов окружения — это вызов getenv, который исключает непосредственное обращение к переменной environ.

const char *getenv(const char * name);

Единственный параметр getenv() — это имя переменной окружения, значение которой интересует. Если переменная существует, getenv() вернет указатель на ее значение. Если переменная не существует в текущем окружении (то есть окружении, на которое указывает environ), функция вернет NULL.

Linux предоставляет два способа добавления строк в программное окружение: setenv() и putenv(). POSIX определяет только putenv(), что делает его более переносимым.

int putenv(const char * string);

Переданный функции параметр string должен иметь форму ИМЯ = ЗНАЧЕНИЕ . putenv() добавляет переменную по имени ИМЯ к текущему окружению и присваивает ей значение ЗНАЧЕНИЕ . Если окружение уже содержит переменную ИМЯ , ее значение изменяется на ЗНАЧЕНИЕ .

BSD определяет функцию setenv(), которую Linux также поддерживает. Это более гибкий и удобный способ добавления переменных к окружению.

int setenv(const char * name, const char * value, int overwrite);

Здесь имя и новое значение переменной окружения передаются раздельно, что обычно программам делать проще. Если overwrite равно 0, окружение не модифицируется, если оно уже содержит переменную по имени name. В противном случае значение переменной модифицируется, как и в putenv().

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

putenv("PATH=/bin:/usr/bin");

setenv("PATH","/bin:/usr/bin", 1);

 

10.3.2 Использование ресурсов

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

Таблица 10.1. Ресурсы процессов, отслеживаемые Linux

Процесс может проверять использование ресурсов им самим, общее использование ресурсов его дочерними процессами либо сумму того и другого.

Системный вызов getrusage() возвращает структуру struct rusage (определенную в ), содержащую информацию о текущем использовании ресурсов.

int getrusage(int who, struct rusage * usage);

Первый параметр, who, сообщает, какой из трех счетчиков ресурсов должен быть возвращен. RUSAGE_SELF возвращает использование ресурсов текущим процессом, RUSAGE_CHILDREN — его дочерними процессами, a RUSAGE_BOTH — общее использование ресурсов текущим процессом и всеми его дочерними процессами. Второй параметр getrusage() — это указатель на struct rusage, куда помещается информация об использовании ресурсов. Хотя struct rusage и содержит относительно немного членов (список унаследован из BSD), большинство этих членов пока не используются Linux). Ниже представлено полное определение этой структуры. В табл. 10.1 описаны члены, используемые в настоящее время Linux.

#include

struct rusage {

 struct timeval ru_utime;

 struct timeval ru_stime;

 long intru_maxrss;

 long intru_ixrss;

 long intru_idrss;

 long intru_isrss;

 long intru_minflt;

 long intru_majfit;

 long intru_nswap;

 long intru_inblock;

 long intru_oublock;

 long intru_msgsnd;

 long intru_msgrcv;

 long intru_nsignals;

 long intru_nvcsw;

 long intru_nivcsw;

};

 

10.3.3. Применение ограничений использования ресурсов

Чтобы помочь в предотвращении неконтролируемого снижения производительности процессами, Unix отслеживает многие ресурсы, которые может использовать процесс, и позволяет системному администратору и самим пользователям накладывать ограничения на расход ресурсов процессами.

Предусмотрены два класса доступных ограничений: жесткие и мягкие ограничения. Жесткие обычно установлены при запуске системы в RLIM_INFINITY, что означает отсутствие каких-либо ограничений. Единственное исключение из этого — RLIMIT_CORE (максимальный размер дампа памяти), который Linux инициирует нулем, чтобы предотвратить неожиданный сброс дампов ядра. Многие дистрибутивы сбрасывают этот лимит при запуске, однако, большинство технических пользователей ожидают появления дампов памяти при некоторых условиях (информацию о дампах памяти можно найти далее в главе). Мягкие ограничения — это те ограничения, которые установлены в ядре в данный момент. Любой процесс может наложить мягкое ограничение на использование ресурса на определенном уровне — равном или более низком, чем установленное жесткое ограничение.

Таблица 10.2. Ограничения ресурсов

Различные ограничения, которые могут быть установлены, перечислены в табл. 10.2 и определены в . Системные вызовы getrlimit() и setrlimit() устанавливают и получают ограничения для отдельного ресурса.

int getrlimit(int resource, struct rlimit *rlim);

int setrlimit(int resource, const struct rlimit *rlim);

Обе эти функции используют структуру struct rlimit, определенную следующим образом:

struct rlimit {

 long int rlim_cur; /* мягкое ограничение */

 long int rlim_max; /* жесткое ограничение */

};

Второй член структуры — rlim_max, указывает жесткое ограничение лимита, переданного в параметре resource, a rlim_cur — мягкое ограничение. Это те же наборы лимитов, которыми манипулируют команды ulimit и limit, одна из которых встроена в большинство командных оболочек.

 

Несмотря на относительно длинную дискуссию, необходимую для описания процесса, создание и уничтожение процессов в Linux достаточно просто.

 

10.4.1. Создание дочерних процессов

В Linux предусмотрены два системных вызова, которые создают новые процессы: fork() и clone(). Как упоминалось ранее, clone() используется для создания потоков, и этот вызов будет кратко описан далее. А сейчас мы сосредоточимся на fork() — наиболее популярном методе создания процессов.

#include

pid_t fork(void);

Этот системный вызов имеет уникальное свойство возвращать управление не один раз, а дважды: один раз в родительском процессе и другой — в дочернем. Обратите внимание, что мы не говорим "первый — в родительском" — написание кода, который делает какие-то предположения относительно предопределенного порядка — очень плохая идея.

Каждый из двух возвратов системного вызова fork() имеет разные значения. В родительский процесс этот системный вызов возвращает pid вновь созданного дочернего процесса, а в дочернем он возвращает 0.

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

#include

#include

#include

int main(void) {

 pid_t child;

 if (!(child = fork())) {

  printf("в дочернем\n");

  exit (0);

 }

 printf("в родительском - дочерний: %d\n", child);

 return 0;

}

 

10.4.2. Наблюдение за уничтожением дочерних процессов

Сбор состояний возврата дочернего процесса называется ожиданием процесса. Это можно делать четырьмя способами, хотя только один из вызовов предоставляется ядром. Остальные три метода реализованы в стандартной библиотеке С. Поскольку системный вызов ядра принимает четыре аргумента, он называется wait4().

pid_t wait4(pid_t pid, int *status, int options, struct rusage *rusage);

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

pid < -1 Ожидать завершения любого дочернего процесса, чей pgid равен абсолютному значению pid.

pid = -1 Ожидать прерывания любого дочернего процесса.

pid = 0 Ожидать завершения дочернего из той же группы процессов, что и текущий.

pid > 0 Ожидать выхода процесса pid.

Второй параметр — это указатель на целое, которое устанавливается в значение, равное соду возврата того процесса, который заставляет wait4() вернуть управление (мы будем зазывать его "проверяемым" процессом). Формат возвращенного состояния довольно закрученный, и для того, чтобы сделать его осмысленным, существует набор макросов.

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

Аргумент options управляет поведением вызова. WHOHANG заставляет функцию немедленно вернуть управление. Если в данный момент нет ни одного процесса, готового сообщить свое состояние, то возвращается 0 вместо допустимого pid. WUNTRACED заставляет wait4() возвратить соответствующий остановленный дочерний процесс. Более подробно о приостановленных процессах рассказывается в главе 15. Оба флажка могут быть объединены вместе битовой операцией "или".

Финальный параметр wait4(), указатель на struct rusage, наполняется информацией об использовании ресурсов проверяемым процессом и всеми его потомками. Более подробная информация об этом давалась при обсуждении getrusage() и RUSAGE_BOTH ранее в главе. Если этот параметр равен NULL, информация о состоянии не возвращается.

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

 

10.4.3. Запуск новых программ

Хотя доступно целых шесть способов запустить одну программу из другой, все они делают почти одно и то же — заменяют текущую выполняющуюся программу другой программой. Обратите внимание на слово "заменяет" — все следы текущей выполняющейся программы при этом исчезают. Если вы хотите оставить исходную программу работающей, вы должны создать новый процесс вызовом fork(), а затем запустить новую программу из дочернего процесса.

Эти шесть функций лишь слегка отличаются по интерфейсу. Только одна из них — execve() — является системным вызовом Linux. Остальные реализованы в библиотеках пользовательского пространства и вызывают execve() для запуска новой программы. Ниже представлены прототипы семейства функций exec().

int execl(const char *path, const char *arg0, ...);

int execlp(const char *file, const char *arg0, ...);

int execle(const char *path, const char *arg0, ...);

int execv(const char *path, const char **argv);

int execvp(const char *file, const char **argv);

int execve(const char *file, const char **argv, const char **envp);

Как уже упоминалось, все эти программы пытаются заменить текущую программу новой. Если это удается, то управление не возвращается (то есть программа, которая вызвала другую программу, уже не выполняется). Если не удается, то возвращается значение -1 и устанавливается код ошибки в errno, как при любом другом системном вызове. Когда новая программа запускается, она принимает массив аргументов (argv) и массив переменных окружения (envp). Каждый элемент envp имеет форму ПЕРЕМЕННАЯ = значение .

Основная разница между функциями семейства exec() состоит в том, как новой программе передаются аргументы командной строки. Функции execl() передают каждый элемент в отдельном аргументе argv, причем список завершается NULL. Традиционно первый элемент argv — это команда, использованная для запуска программы. Например, команда оболочки /bin/cat /etc/passwd /etc/group обычно получается в результате следующей вызова exec:

execl("/bin/cat", "/bin/cat", "/etc/passwd", "/etc/group", NULL);

Первый аргумент — это полный путь к программе, которую требуется выполнить, а остальные аргументы передаются программе в виде argv. Заключительный параметр execl() должен быть равен NULL — это служит признаком конца списка параметров. Если вы пропустите NULL, то, скорее всего, функция завершится ошибкой сегментации либо вернет EINVAL. Окружение, переданное новой программе — это то, на что указывает глобальная переменная environ, как упоминалось ранее в настоящей главе.

Функциям execv аргументы командной строки передаются как массив С строк, имеющих тот же формат, что применяется для передачи argv новой программе.

Последним элементом должен быть NULL для обозначения конца массива, а первый элемент (argv[0]) должен содержать имя вызываемой программы.

Наш пример с bin/cat /etc/passwd /etc/group может быть закодирован, используя execv, следующим образом:

char *argv[] = { "/bin/cat", "/bin/cat", "/etc/passwd", "/etc/group", NULL }; execv("/bin/cat", argv);

Если нужно передать специфическое окружение новой программе, для этого подойдут execle() и execve(). Они в точности похожи на execl() и execv(), но принимают указатель на окружение в качестве последнего аргумента. Окружение устанавливается так же, как argv.

Например, ниже показан один способ запуска /usr/bin/env (эта программа печатает окружение, которое ей передано) с небольшим набором переменных окружения:

char *newenv[] = { "PATH=/bin:/usr/bin", "HOME=/home/sweethome", NULL };

execle("/usr/bin/env", "/usr/bin/env", NULL, newenv);

Вот та же идея, реализованная с помощью execve():

char *argv[] = { "/usr/bin/env", NULL };

char *newenv[] = { "PATH=/bin:/usr/bin", "HOME=/home/sweethome", NULL };

execve("/usr/bin/env", argv, newenv);

Последние две функции, execlp() и execvp(), отличаются от первых двух тем, что выполняют поиск программы, которую нужно запустить, в текущем пути (установленном переменной окружения PATH). Аргументы программы, однако, не модифицируются, поэтому argv[0] не содержит полного пути к запускаемой программе. Ниже показана модифицированная версия нашего первого примера, который ищет cat в текущем PATH.

execlp("cat", "cat", "/etc/passwd", "/etc/group", NULL);

char *argv[] = { "cat", "/etc/passwd", "/etc/group", NULL };

execvp("cat", argv);

Если вместо этого воспользоваться execl() или execv(), этот фрагмент кода завершится ошибкой, если только cat не окажется в текущем каталоге.

Если вы пытаетесь запустить программу со специфическим окружением, при этом желая выполнять поиск пути, вам придется искать путь вручную и использовать execle() или execve(), поскольку ни одна из функций exec() не делает того, что вам нужно.

Обработчики сигналов предохраняются внутри функций exec() несколько неочевидным образом. Этот механизм рассматривается в главе 12.

 

10.4.4. Ускоренное создание процессов с помощью vfork()

Обычно процессы, в которых вызывается fork(), немедленно вызывают exec() для другой программы (это то, что оболочка делает всякий раз, когда вы вводите команду), что делает полную семантику fork() более расточительной по вычислительным ресурсам, чем это необходимо.

Чтобы оптимизировать этот общий случай, существует vfork().

#include

pid_t vfork(void);

Вместо создания совершенно новой среды выполнения для нового процесса vfork() создает новый процесс, который разделяет память с исходным процессом. Ожидается, что новый процесс запустит другой процесс посредством exit() или exec() очень быстро, но его поведение непредсказуемо, если он модифицирует память, возвратит управление из функции vfork(), содержащейся в нем, либо вызовет любую новую функцию. В дополнение к этому исходный процесс приостанавливается, до тех пор, пока новый либо не будет прерван, либо вызовет функцию exec(). Однако не все системы обеспечивают семантику разделения памяти и приостановки родительского процесса vfork(), поэтому приложения не должны полагаться на такое поведение.

 

10.4.5. Уничтожение процессом самого себя

Процессы прерывают себя вызовом либо exit(), либо _exit(). Когда функция процесса main() возвращает управление, стандартная библиотека С вызывает exit() со значением, возвращаемым main() в качестве параметра.

void exit(int exitCode);

void _exit(int exitCode);

Две формы, exit() и _exit(), отличаются тем, что exit() — функция из библиотеки С, a _exit() — системный вызов. Системный вызов _exit() прерывает программу немедленно, и exitCode сохраняется в качестве кода возврата процесса. Когда используется exit(), то перед тем, как запустить системный вызов _exit(exitCode), вызываются функции, зарегистрированные в atexit(). Помимо всего прочего, это позволяет стандартной библиотеке ввода-вывода ANSI/ISO сбросить все свои буферы.

Регистрация функций, которые должны быть запущены при вызове exit(), выполняется с помощью функции atexit():

int atexit(void (*function) (void));

Единственный параметр, переданный atexit() — это указатель на функцию. Когда вызывается exit(), все функции, зарегистрированные через atexit(), вызываются в порядке, обратном тому, в котором они регистрировались. Следует отметить, что если используется _exit() либо процесс прерывается сигналом (подробно о сигналах читайте в главе 12), то функции, зарегистрированные atexit(), не вызываются.

 

10.4.6. Уничтожение других процессов

Разрушение другого процесса почти столь же просто, как создание нового — нужно просто уничтожить его:

int kill(pid_t pid, int signum);

pid должен быть идентификатором процесса, который требуется уничтожить, а signum описывает, как это нужно сделать. Доступны два варианта выполнения операции прерывания дочернего процесса. Вы можете применить SIGTERM, чтобы прервать его "вежливо". Это означает, что процесс при этом может сообщить ядру о том, что кто-то пытается его уничтожить; в результате появляется возможность завершить его корректно (сохранив файлы, например). Процесс может в этом случае игнорировать запрос на прерывание такого типа и продолжать выполняться. Применение значения SIGKILL в качестве параметра signum вызывает немедленное прерывание процесса без каких-либо вопросов. Если signum равно 0, то kill() проверяет, имеет ли тот процесс, что вызвал kill(), соответствующие полномочия, возвращает ноль, если это так, либо ненулевое значение, если полномочий недостаточно. Это обеспечивает процессу возможность проверки корректности pid.

Параметр pid в среде Linux может принимать перечисленные ниже значения.

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

 

10.4.7. Дамп ядра

Хотя мы уже упоминали, что передача SIGTERM и SIGKILL функции kill() прерывает процесс, вы также можете использовать несколько других значений (все они описаны в главе 12). Некоторые из них, такие как SIGABRT, заставляют программу перед уничтожением сбрасывать дамп ядра (dump core).

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

Когда процесс нарушает какие-то системные требования (например, пытается обратиться к памяти, доступ к которой запрещен), ядро прерывает процесс, вызывая встроенную версию kill() с параметром, который заставляет выгрузить дамп ядра. Ядро может уничтожать процессы по разным причинам, включая арифметические ошибки, такие как деление на ноль, либо по причине выполнения программой некорректных инструкций, либо при попытке доступа к запрещенной области памяти. Последняя причина вызывает ошибку сегментации, что выражается в сообщении segmentation fault (core dumped) (ошибка сегментации (дамп ядра сброшен)). Если вы обладаете хоть каким-нибудь опытом программирования в Linux, то наверняка неоднократно получали это сообщение.

Если для процесса установлен лимит на размер файла дампа, равный 0 (рассматривался ранее в этой главе), то никакой дамп ядра не выгружается.

 

Хотя функции fork(), exec() и wait() позволяют программам в полной мере использовать модель процессов Linux, многим приложениям не нужен такой контроль дочерних процессов. Существуют две библиотечных функции, которые упрощают создание дочерних процессов: system() и popen().

 

10.5.1. Запуск и ожидание с помощью

system()

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

int system (const char* cmd);

system() порождает дочерний процесс, который выполняет exec() для /bin/sh, который, в свою очередь, запускает cmd. Исходный процесс ожидает завершения дочерней оболочки и возвращает тот же код, что wait(). Если вам не нужно оставлять в памяти оболочку (что случается редко), cmd должна включать предшествующее слово "exec", которое заставляет оболочку вызывать exec() вместо запуска cmd как подпроцесса.

Поскольку cmd запускается из оболочки /bin/sh, то здесь применимы все обычные правила расширения команд. Ниже показан пример вызова system(), который отображает исходные тексты С из текущего каталога.

#include

#include

int main() {

int result;

result = system("exec ls *.c");

if (!WIFEXITED(result))

 printf("(аварийный выход)\n");

 exit(0);

}

Команда system() должна применяться с большой осторожностью в программах, которые запускаются со специальными полномочиями. Поскольку системная оболочка предоставляет множество мощных средств и сильно зависит от переменных окружения, system() является уязвимым местом в плане безопасности, которым могут воспользоваться злоумышленники для проникновения в систему. Однако до тех пор, пока приложение не является демоном или программой setuid/setgid, вызов system() совершенно безопасен.

 

10.5.2. Чтение и запись из процесса

Хотя system() отображает результат работы команды на устройство стандартного вывода и позволяет дочерним программам читать стандартный ввод, это не всегда идеально. Часто процесс желает читать вывод другого процесса либо отправлять текст на стандартный ввод. popen() облегчает процессам решение этой задачи.

FILE * popen(const char *cmd, const char *mode);

cmd выполняется через оболочку, как и в system(). Параметр mode должен быть "r", если родительский процесс желает читать командный вывод, и "w" — для записи в стандартный ввод дочернего процесса. Следует отметить, что с помощью popen() делать одновременно чтение и запись нельзя.

Два процесса, которые читают и пишут друг в друга, достаточно сложны и выходят за рамки возможностей popen().

popen() возвращает FILE* (как это определено в стандартной библиотеке ввода-вывода ANSI/ISO), который может быть прочитан и записан подобно любому другому потоку stdio, либо NULL, если операция не удается. Когда завершается родительский процесс, он может воспользоваться pclose() для закрытия потока и прерывания дочернего процесса, если он все еще выполняется. Подобно system(), pclose() возвращает состояние дочернего процесса из wait4().

int pclose(FILE *stream);

Ниже приведен пример простой программы-калькулятора, которая использует программу bc для выполнения всей реальной работы. Важно сбрасывать поток, полученный от popen(), после записи в него, чтобы предотвратить буферизацию stdio от задержки вывода (подробности о буферизации стандартных функций библиотеки stdio можно найти в [15]).

 1: /*calc.c*/

 2:

 3: /* Это очень простой калькулятор, который использует внешнюю команду bc

 4:    для выполнения всей работы. Открывает канал к bc, читает команду,

 5:    передает ее bc и завершается. */

 6: #include

 7: #include

 8: #include

 9:

10: int main(void) {

11:  char buf[1024];

12:  FILE *bc;

13:  int result;

14:

15:  /* открыть канал на bc и выйти в случае неудачи */

16:  bc = popen("bc", "w");

17:  if (!bc) {

18:   perror("popen");

19:   return 1;

20:  }

21:

22:  /* пригласить ввести выражение, и прочитать его */

23:  printf("expr:"); fflush(stdout);

24:  fgets(buf, sizeof(buf), stdin);

25:

26:  /* послать выражение bc для вычисления */

27:  fprintf(bc, "%s\n", buf);

28:  fflush(bc);

29:

30:  /* закрыть канал на bc и ожидать выхода из нее */

31:  result = pclose(bc);

32:

33:  if (!WIFEXITED(result))

34:   printf("(аварийный выход)\n");

35:

36:  return 0;

37: }

Подобно system(), popen() запускает команды через системную оболочку и должна использоваться с большой осторожностью, если вызывается из программы со специальными полномочиями.

 

В Linux, как и в других системах Unix, пользователи обычно взаимодействуют с группами взаимосвязанных процессов. Хотя изначально они входят через единственный терминал и используют единственный процесс (а именно — оболочку, предоставляющую интерфейс командной строки), пользователи затем запускают множество процессов в результате перечисленных ниже действий.

• Запуск неинтерактивных заданий в фоновом режиме.

• Переключение между интерактивными заданиями с помощью управления заданиями (job control), которое более подробно обсуждается в главе 15.

• Запуск множества процессов, взаимодействующих через программные каналы.

• Запуск оконной системы, вроде X Window System, которая позволяет открывать несколько терминальных окон.

Чтобы управлять всеми этими процессами, ядру необходимо группировать процессы более сложным образом, чем простое отношение "родительский-дочерний", которое мы описали. Этот способ группировки называется сеансами и группами процессов. На рис. 10.1 показано отношение между сеансами, группами процессов и процессами.

Рис. 10.1. Сеансы, группы процессов и процессы

 

10.6.1. Сеансы

Когда пользователь выходит из системы, ядро должно прервать все процессы, которые пользователь запустил (иначе может остаться множество процессов, которые будут ожидать ввода, а тот никогда не последует). Чтобы упростить эту задачу, процессы организуются в наборы сеансов. Идентификатор сеанса — это то же, что pid процесса, который создает сеанс с помощью системного вызова setsid(). Этот процесс называют лидером сеанса (session leader) для данной группы процессов. Все потомки процесса являются членами сеанса, если только явно не будут удалены из него. Вызов функции setsid() не принимает аргументов, а возвращает идентификатор нового сеанса.

#include

pid_t setsid(void);

 

10.6.2. Управление терминалом

Каждый сеанс привязывается к терминалу, от которого процессы и сеансы получают ввод и куда отправляют свой вывод. Терминал может быть локальной консолью машины, терминальным подключением через последовательный порт или псевдотерминалом, который отображается на окно X либо на сетевое подключение (см. главу 16). Терминал, к которому относится сеанс, называется управляющим терминалом (или управляющим tty) данного сеанса. Терминал может быть управляющим одновременно только для одного сеанса.

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

 

10.6.3. Группы процессов

Одной из главных целей Unix было создание набора простых инструментов, которые могут быть использованы вместе сложными способами (с помощью механизмов, подобных программным каналам). Большинство пользователей Linux делали нечто вроде следующего практического примера этой философии:

ls | grep "^[аА].*\.gz" | more

Другое популярное средство, появившееся в Unix достаточно давно — управление заданиями (job control). Управление заданиями дает возможность пользователям прерывать текущее задание (известное как задание переднего плана (foreground task)) в то время, пока они уходят и делают на терминале что-то другое. Когда приостановленное задание представляет собой последовательность процессов, работающих вместе, система должна отслеживать, какие именно процессы должны быть приостановлены, когда пользователь желает приостановить задание переднего плана. Группы процессов позволяют системе видеть, какие процессы работают вместе, а потому должны управляться совместно средствами управления заданиями.

Процессы добавляются в группы с помощью setpgid().

int setpgid(pid_t pid, pid_t pgid);

pid — это процесс, который должен быть помещен в новую группу (0 обозначает текущий процесс), pgid — это идентификатор группы процессов, к которой должен принадлежать процесс pid, или 0, если процесс должен быть включен в новую группу процессов, чей pgid тот же, что и pid процесса. Подобно сеансам, лидер группы процессов — это процесс, чей pid совпадает в pgid группы.

Правила применения setpgid() несколько сложны.

1. Процесс может устанавливать группу для себя или одного из своих потомков. Он не может изменять группу для любого другого процесса в системе, даже если процесс, вызвавший setpgid(), имеет административные полномочия.

2. Лидер сеанса не может изменить свою группу.

3. Процесс не может быть перемещен в группу, чей лидер представляет другой сеанс, чем он сам. Другими словами, все процессы в группе должны относиться к одному и тому же сеансу.

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

Полный пример групп процессов будет приведен при обсуждении системы управления заданиями в главе 15.

Когда соединение с терминалом теряется, ядро посылает сигнал (SIGHUP; подробнее о сигналах рассказывается в главе 12) лидеру сеанса, содержащему группу процессов переднего плана данного терминала. Обычно это командная оболочка. Это позволит оболочке безусловно прерывать пользовательские процессы, извещая их о том, что пользователь выходит из системы (обычно посредством SIGHUP), либо выполнить некоторые другие действия (или бездействие). Хотя это все может показаться усложненным, это дает возможность лидеру группы сеанса принимать решения о том, как управлять закрывающимися терминалами, вместо того, чтобы возлагать эту обязанность на ядро. Это также дает возможность администраторам гибко управлять политиками пользовательских учетных записей.

Определение группы процесса может быть выполнено просто, с помощью функций getpgid() и getpgrp().

 

10.6.4. Висячие группы процессов

Механизм прерывания процессов (либо возобновления их работы после приостановки) при исчезновении их сеанса довольно сложен. Представьте себе сеанс со многими группами процессов в нем (см. рис. 10.1). Сеанс запущен на терминале, и обычная системная оболочка является его лидером.

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

В этой ситуации каждая такая группа процессов получает название висячей (orphaned). Стандарт POSIX определяет ее как группу процессов, чей родитель является также членом этой группы либо не является членом сеанса этой группы. Другими словами, группа процессов не является висячей до тех пор, пока у нее есть родительский процесс, принадлежащий тому же сеансу, но другой группе.

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

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

Программы, которые не прерываются по сигналу SIGHUP, получают сигнал SIGCONT, который продолжает выполнение приостановленных процессов. Такая последовательность прерывает большинство процессов и обеспечивает оставшимся возможность работать (то есть гарантирует, что они не будет в приостановленном состоянии).

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

 

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

• Простые встроенные команды.

• Запуск внешних команд.

• Перенаправление ввода-вывода (>, | и так далее).

• Управление заданиями.

Полный исходный текст окончательной версии этой оболочки, ladsh4.с, представлен в приложении Б. По мере добавления в ladsh новых средств, изменения исходного текста описываются в тексте книги. Чтобы уменьшить количество изменений, которые мы вносим между версиями, некоторые ранние версии несколько более сложны, чем было бы нужно. Эти небольшие усложнения, однако, далее в книге упрощают разработку оболочки, поэтому будьте терпеливы. Просто пока поверьте, что эти фрагменты кода необходимы; все они будут объяснены позднее.

 

10.7.1. Запуск внешних программ с помощью ladsh

Вот первая (и самая простая) версия ladsh, называемая ladsh1.

  1: /*ladsh1.c*/

  2:

  3: #include

  4: #include

  5: #include

  6: #include

  7: #include

  8: #include

  9: #include

 10: #include

 11: #include

 12: #include

 13:

 14: #define MAX_COMMAND_LEN 250 /* максимальная длина отдельной

 15:                                командной строки */

 16: #define JOB_STATUS_FORMAT "[%d]%-22s%.40s\n"

 17:

 18: struct jobSet {

 19:  struct job *head; /* заголовок списка запущенных заданий */

 20:  struct job *fg;   /* текущее задание переднего плана */

 21: };

 22:

 23: struct childProgram {

 24:  pid_t Pid;   /* 0 на выходе */

 25:  char **argv; /* имя программы с аргументами */

 26: };

 27:

 28: struct job {

 29:  int job Id;       /* номер задания */

 30:  int numProgs;     /* общее кол-во программ в задании */

 31:  int runningProgs; /* кол-во работающих программ */

 32:  char *text;       /* имя задания */

 33:  char *cmdBuf;     /* буфер различных argv */

 34:  pid_t pgrp;       /* идентификатор группы процессов задания */

 35:  struct childProgram *progs; /* массив программ в задании */

 36:  struct job *next; /* для слежения за фоновыми программами */

 37: };

 38:

 39: void freeJob(struct job *cmd) {

 40:  int i;

 41:

 42:  for (i=0; inumProgs; i++) {

 43:   free (cmd->progs[i].argv);

 44:  }

 45:  free(cmd->progs);

 46:  if (cmd->text) free(cmd->text);

 47:   free(cmd->cmdBuf);

 48:  }

 49:

 50:  int getCommand(FILE *source, char *command) {

 51:  if (source == stdin) {

 52:   printf("#");

 53:   fflush(stdout);

 54:  }

 55:

 56:  if (!fgets(command, MAX_COMMAND_LEN, source)) {

 57:   if (source==stdin) printf("\n");

 58:   return 1;

 59:  }

 60:

 61:  /* удалить завершающий перевод строки */

 62:  command[strlen(command) - 1] = '\0';

 63:

 64:  return 0;

 65: }

 66:

 67: /* Возвратить cmd->numProgs как 0, если нет никаких команд (то есть пустая

 68:    строка). Если найдена правильная команда, commandPtr устанавливается в

 69:    указатель на начало следующей команды (если исходная команда имеет более

 70:    одного задания, ассоциированного с ней) или NULL, если

 71:    больше нет команд.*/

 72: int parseCommand(char **commandPtr, struct job *job, int *isBg) {

 73:  char *command;

 74:  char *returnCommand = NULL;

 75:  char *src, *buf;

 76:  int argc = 0;

 77:  int done = 0;

 78:  int argvAlloced;

 79:  char quote = '\0';

 80:  int count;

 81:  struct childProgram *prog;

 82:

 83:  /* Пропустить ведущие пробелы */

 84:  while(**commandPtr && isspace(**commandPtr)) (*commandPtr)++;

 85:

 86:  /* здесь обрабатываются пустые строки и ведущие символы '#' */

 87:  if (!**commandPtr || (**commandPtr=='#')) {

 88:   job->numProgs = 0;

 89:   *commandPtr = NULL;

 90:   return 0;

 91:  }

 92:

 93:  *isBg = 0;

 94:  job->numProgs = 1;

 95:  job->progs = malloc(sizeof(*job->progs));

 96:

 97:  /* Мы устанавливаем элементы argv в указатели внутри строки.

 98:     Память освобождается freeJob().

 99:

100:     Получение чистой памяти позволяет далее иметь дело с

101:     NULL-завершающимися вещами и делает все остальное немного

102:     яснее (к тому же, это добавляет эффективности) */

103:  job->cmdBuf = command = calloc(1, strlen(*commandPtr) + 1);

104:  job->text = NULL;

105:

106:  prog = job->progs;

107:

108:  argvAlloced = 5;

109:  prog->argv = malloc(sizeof(*prog->argv) * argvAlloced);

110:  prog->argv[0] = job->cmdBuf;

111:

112:  buf = command;

113:  src = *commandPtr;

114:  while (*src && !done) {

115:   if (quote==*src) {

116:    quote='\0';

117:   } else if (quote) {

118:    if (*src == '\\') {

119:     src++;

120:     if (!*src) {

121:      fprintf(stderr,

122:       "ожидается символ после\\\n");

123:      freeJob(job);

124:      return 1;

125:     }

126:

127:     /* в оболочке, "\'" должно породить \' */

128:     if (*src != quote) *buf++='\\';

129:    }

130:    *buf++ = *src;

131:   } else if (isspace(*src)) {

132:    if (*prog->argv[argc]) {

133:     buf++, argc++;

134:     /* +1 здесь оставляет место для NULL,

135:        которым завершается argv */

136:     if ((argc+1) == argvAlloced) {

137:      argvAlloced += 5;

138:      prog->argv = realloc(prog->argv,

139:       sizeof(*prog->argv)*argvAlloced);

140:     }

141:     prog->argv[argc]=buf;

142:    }

143:   } else switch(*src) {

144:   case '"':

145:   case '\'':

146:    quote = *src;

147:    break;

148:

149:   case '#' : /* комментарий */

150:    done=1;

151:    break;

152:

153:   case '&': /* фоновый режим */

154:    *isBg = 1;

155:   case ';': /* множественные команды */

156:    done=1;

157:    return Command = *commandPtr + (src - *commandPtr) + 1;

158:    break;

159:

160:   case '\\' :

161:    src++;

162:    if (!*src) {

163:     freeJob(job);

164:     fprintf(stderr, "ожидается символ после \\\n");

165:     return 1;

166:    }

167:    /* двигаться дальше */

168:   default:

169:    *buf++=*src;

170:   }

171:

172:   src++;

173:  }

174:

175:  if (*prog->argv[argc]) {

176:   argc++;

177:  }

178:  if (!argc) {

179:   freeJob(job);

180:   return 0;

181:  }

182:  prog->argv[argc]=NULL;

183:

184:  if (!returnCommand) {

185:   job->text = malloc(strlen(*commandPtr) + 1);

186:   strcpy(job->text,*commandPtr);

187:  } else {

188:   /* Это оставляет хвостовые пробелы, что несколько излишне */

189:

190:   count = returnCommand - *commandPtr;

191:   job->text = malloc(count + 1);

192:   strncpy(job->text,*commandPtr,count);

193:   job->text[count] = '\0';

194:  }

195:

196:  *commandPtr = returnCommand;

197:

198:  return 0;

199: }

200:

201: int runCommand(struct jobnewJob, struct jobSet *jobList,

202:  intinBg) {

203:  struct job *job;

204:

205:  /* обходной путь "вручную" - мы не используем fork(),

206:     поэтому не можем легко реализовать фоновый режим */

207:  if (!strcmp(newJob.progs[0].argv[0], "exit")) {

208:   /* это должно вернуть реальный код возврата */

209:   exit(0);

210:  } else if(!strcmp(newJob.progs[0].argv[0], "jobs")) {

211:   for (job = jobList->head; job; job = job->next)

212:    printf(JOB_STATUS_FORMAT, job->jobId, "Работаю",

213:     job->text);

214:   return 0;

215:  }

216:

217:  /* у нас пока только одна программа на дочернее задание,

218:     потому это просто */

219:  if (!(newJob.progs[0].pid = fork())) {

220:   execvp(newJob.progs[0].argv[0],newJob.progs[0].argv);

221:   fprintf(stderr, "exec() для %s потерпела неудачу: %s\n",

222:    newJob.progs[0].argv[0],

223:   strerror(errno));

224:   exit(1);

225:  }

226:

227:  /* поместить дочернюю программу в отдельную группу процессов */

228:  setpgid(newJob.progs[0].pid,newJob.progs[0].pid);

229:

230:  newJob.pgrp = newJob.progs[0].pid;

231:

232:  /* найти идентификатор для задания */

233:  newJob.jobld = 1;

234:  for (job = jobList->head; job; job = job->next)

235:   if (job->jobId >= newJob.jobId)

236:    newJob.jobId = job->jobId+1;

237:

238:  /* задание для списка заданий */

239:  if (!jobList->head) {

240:   job = jobList->head = malloc(sizeof(*job));

241:  } else {

242:   for (job = jobList->head; job->next; job = job->next);

243:   job->next = malloc(sizeof(*job));

244:   job = job->next;

245:  }

246:

247:  *job = newJob;

248:  job->next = NULL;

249:  job->runningProgs = job->numProgs;

250:

251:  if (inBg) {

252:   /* мы не ждем завершения фоновых заданий - добавить

253:      в список фоновых заданий и оставить в покое */

254:

255:   printf("[%d]%d\n", job->jobId,

256:    newJob.progs[newJob.numProgs-1].pid);

257:  } else {

258:   jobList->fg=job;

259:

260:   /* переместить новую группу процессов на передний план */

261:

262:   if (tcsetpgrp(0,newJob.pgrp))

263:    perror("tcsetpgrp");

264:  }

265:

266:  return 0;

267: }

268:

269: void removeJob(struct jobSet *jobList, struct job *job) {

270:  struct job *prevJob;

271:

272:  freeJob(job);

273:  if (job == jobList->head) {

274:   jobList->head=job->next;

275:  } else {

276:   prevJob = jobList->head;

277:   while (prevJob->next != job) prevJob = prevJob->next;

278:   prevJob->next=job->next;

279:  }

280:

281:  free(job);

282: }

283:

284: /* Проверить, завершился ли какой-то из фоновых процессов -

285:    если да, выяснить, почему и определить, завершилось ли задание */

286: void checkJobs(struct jobSet *jobList) {

287:  struct job *job;

288:  pid_t childpid;

289:  int status;

290:  int progNum;

291:

292:  while ((childpid = waitpid(-1, &status, WNOHANG))>0) {

293:   for (job = jobList->head;job;job = job->next) {

294:    progNum = 0;

295:    while (progNumnumProgs &&

296:     job->progs[progNum].pid != childpid)

297:     progNum++;

298:    if (progNumnumProgs) break;

299:   }

300:

301:   job->runningProgs--;

302:   job->progs[progNum].pid = 0;

303:

304:   if (!job->runningProgs) {

305:    printf(JOB_STATUS_FORMAT,job->jobId,"Готово",

306:     job->text);

307:    removeJob(jobList, job);

308:   }

309:  }

310:

311:  if (childpid == -1 && errno!= ECHILD)

312:   perror("waitpid");

313:  }

314:

315:  int main(int argc, const char **argv) {

316:   char command [MAX_COMMAND_LEN + 1];

317:   char *nextCommand = NULL;

318:   struct jobSetjobList = {NULL, NULL};

319:   struct jobnewJob;

320:   FILE *input = stdin;

321:   int i;

322:   int status;

323:   int inBg;

324:

325:   if (argc>2) {

326:    fprintf(stderr,"Непредвиденные аргументы; использование: ladsh1 "

327:     "<команды>\n");

328:    exit(1);

329:   } else if (argc == 2) {

330:    input = fopen(argv[1], "r");

331:    if (!input) {

332:     perror("fopen");

333:     exit(1);

334:    }

335:   }

336:

337:   /* не обращать внимания на этот сигнал; он только вводит

338:      в заблуждение и не имеет особого значения для оболочки */

339:   signal(SIGTTOU, SIG_IGN);

340:

341:   while(1) {

342:   if (!jobList.fg) {

343:    /* нет заданий переднего плана */

344:

345:    /* проверить, завершились ли какие-то фоновые процессы */

346:    checkJobs(&jobList);

347:

348:    if (!nextCommand) {

349:     if (getCommand(input, command)) break;

350:     nextCommand=command;

351:    }

352:

353:    if (!parseCommand(&nextCommand, &newJob, &inBg) &&

354:     newJob.numProgs) {

355:     runCommand(newJob,&jobList,inBg);

356:    }

357:   } else {

358:    /* задание выполняется на переднем плане; ждать завершения */

359:    i = 0;

360:    while (!jobList.fg->progs[i].pid) i++;

361:

362:    waitpid(jobList.fg->progs[i].pid,&status,0);

363:

364:    jobList.fg->runningProgs--;

365:    jobList.fg->progs[i].pid=0;

366:

367:    if (!jobList.fg->runningProgs) {

368:     /* дочернее завершилось */

369:

370:     removeJob(&jobList, jobList.fg);

371:     jobList.fg = NULL;

372:

373:     /* переместить оболочку на передний план */

374:     if (tcsetpgrp(0, getpid()))

375:      perror("tcsetpgrp");

376:    }

377:   }

378:  }

379:

380:  return 0;

381: }

Эта версия не делает ничего, кроме запуска внешней программы с аргументами, поддержки комментариев стиля # (все, что следует за символом #, игнорируется), и позволяет программам выполняться в фоновом режиме. Она работает как интерпретатор простых сценариев оболочки, написанных в нотации #!, но ничего сверх этого не делает. Она разработана в качестве имитации обычного интерпретатора оболочки, используемого в системах Linux, несмотря на то, что в значительной степени упрощена.

Прежде всего, взглянем на структуры данных, которые здесь используются. На рис. 10.2 показаны структуры данных, используемые в ladsh1.с для отслеживания запускаемых дочерних процессов, на примере применения программы grep в фоновом режиме и links — в режиме переднего плана, struct jobSet описывает набор функционирующих заданий. Он содержит связный список заданий и указатель на текущее задание, выполняемое на переднем плане. Если такового нет, то указатель равен NULL, ladsh1.с использует struct jobSet для того, чтобы отслеживать задания, выполняемые в данный момент в фоновом режиме.

Рис. 10.2. Структуры данных, описывающие задания для ladsh1.с

struct childProgram описывает отдельную выполняемую программу. Это не совсем то же самое, что задание — в конце концов, каждое задание может состоять из нескольких программ, связанных по программным каналам. Для каждой дочерней программы ladsh отслеживает pid, имя программы и аргументы командной строки. Первый элемент argv, argv[0], содержит имя запущенной программы, которое передается также потомку в виде первого аргумента.

Множество программ объединяется в одно задание с помощью struct job. Каждое задание имеет уникальный идентификатор в оболочке, соответствующее количество программ, составляющих задание (хранимых в progs, указателе на массив struct childProgram), а также указатель на другое (следующее) задание, что позволяет объединять их вместе в связный список (который описывает struct jobSet). Задание также отслеживает, сколько отдельных программ составляет его, и сколько их них все еще выполняются (поскольку не все компоненты задания могут завершаться одновременно). Остальные два члена — text и cmdBuf — служат в качестве буферов для хранения различных строк, которые используются структурами struct childProgram, содержащимися в задании.

Большая часть struct jobSet состоит из динамически распределенной памяти, которая должна быть освобождена по завершении задания. Первая функция в ladsh1.с, freeJob(), освобождает память, использованную заданием.

Следующая функция, getCommand(), получает команду, введенную пользователем, и возвращает строку. Если команды читаются из файла, то никакого приглашения не выводится (вот почему код сравнивает входной файловый поток со stdin).

parseCommand() разбивает строку команды в структуру struct job для использования в ladsh. Первый аргумент — это указатель на указатель на команду. Если в строке множество команд, он переставляется на начало следующей команды. Он устанавливается в NULL, когда завершается разбор последней команды в строке. Это позволяет parseCommand() разбирать только одну команду при каждом вызове и дает возможность вызывающей функции просто разбирать строку за несколько вызовов. Следует отметить, что несколько программ, объединенных каналами, не рассматриваются как отдельные команды — независимыми друг от друга считаются только команды, разделенные символами ; или &. Поскольку parseCommand() — это просто пример разбора строк, мы не будем углубляться в детали ее работы.

Функция runCommand() отвечает за запуск отдельного задания. Она принимает структуру struct job, описывающую запускаемое задание, список заданий, выполняющихся в данный момент, а также флаг, указывающий, должно ли задание выполняться в фоновом режиме или же на переднем плане.

Пока ladsh не поддерживает каналов, поэтому каждое задание может состоять только из одной программы (хотя большая часть инфраструктуры, поддерживающей каналы, уже присутствует в ladsh1.с). Если пользователь запускает exit, происходит немедленный выход из программы. Это пример встроенной команды, которую выполняет сама оболочка для обеспечения правильного поведения. Другая встроенная команда — jobs — также здесь реализована.

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

219: if (!(newJob.progs[0].pid = fork())) {

220:  execvp(newJob.progs[0].argv[0], newJob.progs[0].argv);

221:  fprintf(stderr, "exec() для %s потерпела неудачу: %s\n",

222:   newJob.progs[0].argv[0],

223:  strerror(errno));

224:  exit(1);

225: }

Во-первых, с помощью fork() порождается дочерний процесс. Родитель сохраняет идентификатор pid дочернего процесса в newJob.progs[0].pid, тогда как дочерний процесс сохраняет там 0 (помните, что родитель и потомок имеют разные образы памяти, хотя изначально они и содержат одинаковую информацию). В результате управление в дочернем процессе входит в тело оператора if, в то время как родитель пропускает его. Дочерний немедленно запускает новую программу с помощью вызова execvp(). Если ему этот вызов не удается, печатается сообщение об ошибке и работа завершается. Это все необходимо, чтобы породить простой дочерний процесс.

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

Следующая функция, checkJobs(), ищет фоновые задания, которые были завершены, и соответствующим образом чистит список работающих заданий. Для каждого процесса, который был завершен (помните, что waitpid() возвращает только информацию о завершенных процессах, если только не было указано WUNTRACED), оболочка делает следующие вещи.

1. Ищет задание, частью которого является процесс.

2. Помечает программу как завершенную (устанавливая сохраненный pid равным 0) и уменьшает количество работающих программ в задании на единицу.

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

Процедура main() из ladsh1.с контролирует поток управления оболочки. Если при ее запуске ей передан аргумент, он трактуется как имя файла, из которого нужно читать последовательность команд. В противном случае в качестве источника команд используется stdin. Затем программа игнорирует сигнал SIGTTOU. Это элемент "магии" управления заданиями, который обеспечивает, что все происходит гладко. Смысл этого будет пояснен в главе 15. Пока что это только скелет.

Остаток функции main() составляет главный цикл программы. Условие выхода из цикла не предусмотрено. Программа завершается вызовом exit() внутри функции runCommand().

Переменная nextCommand указывает на исходное (не разобранное) строковое представление следующей команды, которая должна быть выполнена, либо NULL, если команда должна быть прочитана из входного файла, коим обычно является stdin. Когда никакое задание не выполняется на переднем плане, ladsh вызывает checkJobs() для проверки выполняющихся фоновых заданий, читает следующую команду из входного файла, если nextCommand равно NULL, затем разбирает и выполняет следующую команду.

Когда выполняется задание переднего плана, ladsh1.с ожидает завершения одного из процессов задания переднего плана. Когда все процессы задания переднего плана завершены, задание исключается из списка запущенных заданий и ladsh1.с читает следующую команду, как описано выше.

 

Каждый файл в системе имеет как тип (вроде неименованного канала или символьного устройства), так и набор прав доступа, определяющих, какие процессы могут иметь доступ к файлу. Тип файла и права доступа комбинируются в 16-битное значение (тип short в С), называемое режимом файла (file mode).

Младшие 12 бит режима файла представляют права, регламентирующие доступ к файлу, или модификаторы доступа. Они служат для множества функций. Наиболее важной функцией является возможность изменять идентификатор эффективного пользователя и идентификаторы групп файла при его выполнении.

Режим файла обычно записывается в виде шести восьмеричных разрядов. Представленные в восьмеричном виде, три младших разряда содержат модификаторы доступа файла, а два старших разряда указывают на его тип. Например, файл с режимом 0041777 имеет тип 04, модификатор прав 1 и биты доступа 0777. Аналогично, файл с режимом 0100755 имеет тип 010, не имеет установленного модификатора доступа, а правами доступа к нему являются 0755.

 

11.1.1. Права доступа к файлу

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

Попробуем немного конкретизировать последний абзац с помощью нескольких примеров. Команда Linux chmod дает возможность пользователю специфицировать режим доступа в восьмеричном виде и затем применить его к одному или более файлам. Если имеется файл somefile, который мы хотим сделать доступным для записи только его владельцу, а всем пользователям (включая владельца) разрешить его чтение, мы должны использовать режим 0644 (помните, это восьмеричные цифры). Ведущая цифра 6 — это в двоичном виде 110, а это означает, что тип пользователя, к которому она относится (в данном случае — владелец), имеет право как читать, так и писать в файл; 4 в двоичном виде выглядит как 010, что дает остальным пользователям (членам группы и прочим) права только для чтения.

$ chmod 0644 somefile

$ ls -l somefile

-rw-r--r-- 1 ewt devel 31 Feb 15 15:12 somefile

Если мы хотим позволить любому члену группы devel писать в файл, то должны использовать режим 0664.

$ chmod 0664 somefile

$ ls -l somefile

-rw-rw-r-- 1 ewt devel 31 Feb 15 15:12 somefile

Если somefile — сценарий оболочки (программы, которые используют #! в начале для указания командного интерпретатора), который мы хотим запускать на выполнение, необходимо сообщить системе, что файл является исполняемым, включив бит выполнения — в данном случае мы позволяем владельцу читать, писать и запускать файл, а членам группы devel — читать и запускать этот файл. Всем другим пользователям запрещено манипулировать файлом любым образом.

$ chmod 0750 somefile

$ ls -l somefile

-rwxr-x--- 1 ewt devel 31 Feb 15 15:12 somefile

Каталоги имеют тот же набор бит доступа, что и нормальные файлы, но со слегка отличающейся семантикой. Права чтения разрешают процессам доступ к самому каталогу, что дает возможность пользователям получать список содержимого каталога. Права на запись позволяют процессу создавать новые файлы в каталоге и удалять существующие. Бит выполнения, однако, не транслируется так однозначно (что вообще должно означать выполнение каталога?). Это позволяет процессу осуществлять поиск в каталоге, а это означает, что он может иметь доступ к файлу в каталоге, если он знает имя этого файла.

Большинство системных каталогов на машинах Linux имеют права доступа 0755 и принадлежат пользователю root. Это дает возможность пользователям системы просматривать файлы в каталоге и получать доступ к ним по имени, но разрешает запись в каталоги только пользователю root. Анонимные ftp-сайты, которые позволяют любому пользователю отправлять файлы, но не дают возможность им загружать их до тех пор, пока администратор не просмотрит их содержимое, обычно устанавливают права на входящие каталоги в значение 0722. Это позволяет всем пользователям создавать новые файлы в каталоге, не предоставляя им возможность ни видеть содержимое каталога, ни получать доступа к файлам.

Дополнительную информацию о правах доступа к файлам можно найти в любой книге по Linux или Unix.

 

11.1.2. Модификаторы прав доступа к файлам

Модификаторы прав доступа файлов — это также битовые маски, значения которых представляют биты setuid, setgid и sticky-бит ("липкий" бит). Если бит setuid установлен для исполняемого файла, то эффективный идентификатор пользователя процесса устанавливается равным идентификатору владельца файла, когда программы выполняется (в главе 10 можно найти информацию о том, почему это удобно). Бит setgid ведет себя аналогичным образом, но устанавливает эффективный идентификатор группы в значение группы файла. Бит setuid не имеет значения для неисполняемых файлов, но если бит setgid устанавливается для неисполняемого файла, любая блокировка, выполняемая над файлом, носит обязательный, а не рекомендательный характер (см. главу 13). В Linux биты setuid и setgid игнорируются для сценариев оболочки, поскольку устанавливать setuid для сценариев было бы опасно.

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

Sticky-бит — последний значащий бит в разряде модификатора доступа к файлу, имеет интересную историю, связанную с его наименованием. Старые реализации Unix должны были загружать в память всю программу целиком, прежде чем начать выполнять ее. Это означало, что крупные программы отнимали значительное время на запуск, что было довольно-таки неприятно. Если же программа имела установленный sticky-бит, то операционная система пыталась сохранить ее "привязанной" в памяти настолько долго, насколько возможно, даже когда эта программа не запущена, чтобы уменьшить время запуска. Хотя это было немного некрасиво, но работало достаточно хорошо с часто используемыми программами, такими как компилятор С. Современные реализации Unix, включая Linux, используют загрузку по требованию — кусочек за кусочком, что сделало sticky-бит излишним, поэтому Linux игнорирует его для обычных файлов.

Sticky-бит по-прежнему используется для каталогов. Обычно любой пользователь с правами записи в каталог может удалить любой файл в этом каталоге. Однако если sticky-бит каталога установлен, файлы могут быть удалены только пользователем-владельцем либо пользователем root. Такое поведение удобно, если каталог служит репозиторием для файлов, созданных многими пользователями, например, /tmp.

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

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

Таблица 11.1. Константы прав доступа к файлам

 

11.1.3. Типы файлов

Старшие четыре бита режима файла указывают тип файла. В табл. 11.2 перечислены константы, имеющие отношение к типам файлов. Объединение с помощью битовой операции "И" любых этих констант с режимом файла порождает ненулевое значение, если бит установлен.

Таблица 11.2. Константы типов файлов

Описанные ниже макросы принимают в качестве аргумента режим файла и возвращают true или false.

 

11.1.4. Маска umask процесса

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

Текущая установка umask для процесса выполняется системным вызовом umask().

#include

int umask(int newmask);

Возвращается старое значение и устанавливается новое значение umask процесса. Для файла могут быть указаны только права на чтение, запись и исполнение — вы не можете использовать umask для запрещения установки setuid, setgid или sticky-бита. Команда umask представлена в большинстве командных процессоров и позволяет пользователю устанавливать umask для самой командной оболочки и всех его последующих дочерних процессов.

В качестве примера, команда touch создает новые файлы с правами 0666 (общие права на чтение и запись). Так как пользователю подобное редко подходит, он может заставить команду touch отключать общие и групповые права записи для файла с помощью команды umask 022, как показано ниже.

$ umask 022

$ touch foo

$ ls -l foo

-rw-r--r-- 1 ewt ewt 0 Feb 24 21:24 foo

Если он предпочитает давать права на запись группе, то может вместо этого назначит umask 002.

$ umask 002

$ touch foo

$ ls -l foo

-rw-rw-r-- 1 ewt ewt 0 Feb 24 21:24 foo

Если же он хочет, чтобы его файлы были доступны только ему, это обеспечит umask 077.

$ umask 077

$ touch foo

$ ls -l foo

-rw------- 1 ewt ewt 0 Feb 24 21:24 foo

umask процесса влияет на системные вызовы open(), creat(), mknod() и mkdir().

 

Поскольку значительная часть системных вызовов Linux манипулирует файлами, начнем с демонстрации наиболее широко используемых функций. Более специализированные функции обсудим далее в настоящей главе. Функции, применяемые для чтения каталогов, представлены в главе 14, чтобы сделать настоящую главу более краткой.

 

11.2.1. Файловые дескрипторы

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

Первые три файловых дескриптора для процессов (0, 1 и 2) имеют стандартное назначение. Первый, 0, известен как стандартный ввод (stdin) и является местом, откуда программы должны получать свой интерактивный ввод. Файловый дескриптор 1 называется стандартным выводом (stdout), и большая часть вывода программ должна быть направлена в него. Сообщения об ошибках должны направляться в стандартный поток ошибок (stderr), который имеет файловый дескриптор 2. Стандартная библиотека С следует этим правилам, поэтому gets() и printf() используют stdin и stdout соответственно, и это соглашение дает возможность командным оболочкам правильно перенаправлять ввод и вывод процессов.

Заголовочный файл представляет макросы STDIN_FILENO, STDOUT_FILENO и STDERR_FILENO, которые вычисляются как файловые дескрипторы stdin, stdout и stderr соответственно. Использование этих символических имен делает код более читабельным.

Многие из файловых операций, которые манипулируют файловыми узлами inode, доступны в двух формах. Первая форма принимает в качестве аргумента имя файла. Ядро использует этот аргумент для поиска inode файла и выполняет соответствующую операцию над ним (обычно это включает следование символическим ссылкам). Вторая форма принимает файловый дескриптор в качестве аргумента и выполняет операцию над inode, на который он ссылается. Эти два набора системных вызовов используют похожие имена, но системные вызовы, работающие с файловыми дескрипторами, имеют префикс f. Например, системный вызов chmod() изменяет права доступа для файла, ссылка на который осуществляется по имени; fchmod() устанавливает права доступа к файлу, ссылаясь на него по указанному файловому дескриптору.

Чтобы меньше тратить слов, мы представим обе версии системных вызовов, если они существуют, а обсуждать будет только первую из их (та, которая использует имена файлов).

 

11.2.2. Закрытие файлов

Одной из операций, которые одинаковы для файлов всех типов, является закрытие файла. Ниже показано, как закрыть файл.

#include

int close(int fd);

Очевидно, что это базовая операция. Однако есть один важный момент, касающийся закрытия файлов, о котором следует помнить — она может завершиться сбоем. Некоторые системы (в первую очередь, следует вспомнить сетевые файловые системы вроде NFS) не пытаются поместить последнюю порцию записываемых данных в файл до тех пор, пока он не будет закрыт. Если такая операция вызовет сбой (например, по причине недоступности удаленного хоста), то close() вернет ошибку. Если ваше приложение пишет данные, но не синхронизирует записи (см. обсуждение O_SYNC в следующем разделе), то вы всегда должны проверять результат закрытия файла. Если close() дает сбой, то это значит, что обновленный файл поврежден самым непредсказуемым образом! К счастью подобное случается достаточно редко.

 

11.2.3. Открытие файлов в файловой системе

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

#include

#include

int open(char *pathname, int flags, mode_t mode);

int creat(char *pathname, mode_t mode);

Функция open() возвращает файловый дескриптор, указывающий на pathname. Если возвращенное значение меньше нуля, значит, произошла ошибка (как всегда, errno содержит код ошибки). Аргумент flags описывает тип доступа, который нужен вызывающему процессу, а также управляет различными атрибутами открытия и манипулирования файлом. Режим доступа всегда должен быть указан, и он может быть одним из следующих: O_RDONLY, O_RDWR либо O_WRONLY, что запрашивает доступ, соответственно, только по чтению, по чтению и записи либо только по записи. С этим режимом может быть объединены логическим "И" следующие значения для управления прочей семантикой файлов.

Параметр mode указывает права доступа для файла, если он создается и если он модифицируется текущей установкой umask процесса. Если не указано O_CREAT, то mode игнорируется.

Функция creat() в точности эквивалентна следующему вызову:

open(pathname, O_CREAT | O_WRONLY | O_TRUNC, mode)

Мы не используем creat() в этой книге, потому что находим функцию open() более простой для чтения и понимания.

 

11.2.4. Чтение, запись и перемещение

Хотя есть несколько способов читать и писать файлы, мы обсудим здесь только простейшие из них. Чтение и запись почти идентичны, поэтому рассмотрим их одновременно.

#include

size_t read(int fd, void * buf, size_t length);

size_t read(int fd, const void * buf, size_t length);

Обе функции принимают файловый дескриптор fd, указатель на буфер buf и длину буфера length, read() читает из файлового дескриптора и помещает полученные данные в буфер; write() пишет length байт из буфера в файл. Обе функции возвращают количество переданных байт, или -1 в случае ошибки (это означает, что ничего не было прочитано или записано).

Теперь, когда мы описали эти системные вызовы, рассмотрим простой пример, создающий файл hw в текущем каталоге и записывающий в него строку "Добро пожаловать!".

 1: /* hwwrite.с */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7: #include

 8:

 9: int main(void) {

10:  int fd;

11:

12:  /* открыть файл, создавая его, если он не существовал, и удаляя

13:     его содержимое в противном случае */

14:  if ((fd = open("hw", O_TRUNC | O_CREAT | O_WRONLY, 0644)) < 0) {

15:   perror("open");

16:   exit(1);

17:  }

18:

19:  /* магическое число 18 - это кол-во символов, которые

20:     будут записаны */

21:  if (write(fd, "Добро пожаловать!\n", 18) != 18) {

22:   perror("write");

23:   exit(1);

24:  }

25:

26:  close(fd);

27:

28:  return 0;

29: }

Ниже показано, что получится, если запустить hwwrite.

$ cat hw

cat: hw: No such file or directory

cat: hw: Файл или каталог не существует

$ ./hwwrite

$ cat hw

Добро пожаловать!

$

Для изменения этой программы, чтобы она читала файл, нужно просто изменить open(), как показано ниже, и заменить write() статической строки на read() в буфер.

open("hw", O_RDONLY);

Файлы Unix можно разделить на две категории: просматриваемые (seekable) и непросматриваемые (nonseekable). Непросматриваемые файлы представляют собой каналы, работающие в режиме "первый вошел — первый вышел" (FIFO), которые не поддерживают произвольное чтение или запись, их данные не могут быть перечитаны или перезаписаны. Просматриваемые файлы позволяют читать и писать в произвольное место файла. Каналы и сокеты являются не просматриваемыми файлами; блоковые устройства и обычные файлы являются просматриваемыми.

Поскольку FIFO — это непросматриваемые файлы, то, очевидно, что read() читает их с начала, a write() пишет в конец. С другой стороны, просматриваемые файлы не имеют очевидной точки для этих операций. Вместо этого здесь вводится понятие "текущего" положения, которое перемещается вперед после операции. Когда просматриваемый файл изначально открывается, текущее положение устанавливается в его начало, со смещением 0. Если затем из него читается 10 байт, то текущее положение перемещается в точку со смещением 10 от начала, а запись 5 байт переписывает данные, начиная с одиннадцатого байта в файле (то есть, со смещения 10, где расположена текущая позиция после чтения). После такой записи текущая позиция находится в позиции, смещенной на 15 относительно начала файла — сразу после перезаписанных данных.

Если текущая позиция совпадает с концом файла и процесс пытается читать их этого файла, то read() возвращает 0 вместо ошибки. Если же данные записываются в конец файла, то он растет с тем, чтобы вместить дополнительные данные, и его текущая позиция устанавливается в конец файла. Каждый файловый дескриптор отслеживает независимую текущую позицию (она не хранится в файловом inode), поэтому если файл открыт множество раз множеством процессов, или несколько раз одним и тем же процессом, то чтения и записи, выполняемые через один дескриптор, никак не влияют на позиции чтения и записи, выполненные через другой дескриптор. Конечно, множественные операции записи могут повредить файл другими способами, поэтому блокировка определенного рода в такой ситуации может понадобиться.

Файлы, открытые с флагом O_APPEND ведут себя несколько иначе. Для таких файлов текущая позиция перемещается в конец файла перед тем, как ядро осуществит в него запись. После записи текущая позиция перемещается в конец записанных данных, как обычно. Для файлов, работающих в режиме только для добавления, это гарантирует, что текущая позиция файла всегда будет находиться в его конце немедленно после вызова write().

Приложения, которые хотят читать и писать данные с произвольного места файла, должны установить текущую позицию перед выполнением операции чтения или записи данных, используя lseek().

#include

int lseek(int fd, off_t offset, int whence);

Текущая позиция для файла fd перемещается на offset байт относительно whence, где whence принимает одно из следующих значений:

SEEK_SET Начало файла.

SEEK_CUR Текущая позиция в файле.

SEEK_END Конец файла.

Для SEEK_CUR и SEEK_END значение offset может быть отрицательным. В этом случае текущая позиция перемещается в сторону начала файла (от whence), а не в сторону конца. Например, приведенный ниже код перемещает текущую позицию на 5 байт назад от конца файла.

lseek(fd, -5, SEEK_END);

Системный вызов lseek() возвращает новую текущую позицию в файле относительно его начала, либо -1 в случае ошибки. То есть lseek(fd, 0, SEEK_END) — это просто способ определения размера файла, но следует убедиться, что вы сбросили текущую позицию, прежде чем читать из fd.

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

Процесс A                Процесс B

lseek(fd, 0, SEEK_END);

                        lseek(fd, 0, SEEK_END);

                        write (fd, buf, 10);

write(fd, buf, 5);

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

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

Части файлов, которые "создаются" подобным образом, называют "дырками" (holes). Чтение из такой "дырки" в файле возвращает буфер, полный двоичных нулей, а запись в них может завершиться ошибкой по причине отсутствия свободного пространства на диске. Все это значит, что вызов lseek() не должен применяться для резервирования дискового пространства для позднейшего использования, поскольку такое пространство может быть и не выделено. Если ваше приложение нуждается в выделении некоторого дискового пространства для последующего использования, вы должны применять write(). Файлы с "дырками" часто используют для хранения редко расположенных в них данных, таких как файлы, представляющие хеш-таблицы.

Для простой демонстрации "дырок" в файлах, основанной на командной оболочке, рассмотрим следующий пример (/dev/zero — это символьное устройство, которое возвращает столько двоичных нулей, сколько процесс пытается прочитать из него).

$ dd if=/dev/zero of=foo bs=1k count=10

10+0 records in

10+0 records out

$ ls -l foo

-rw-rw-r-- 1 ewt ewt 10240 Feb 6 21:50 foo

$ du foo

10 foo

$ dd if=/dev/zero of=bar bs=1k count=1 seek=9

1+0 records in

1+0 records out

$ ls -l bar

-rw-rw-r-- 1 ewt ewt 10240 Feb 6 21:50 foo

$ du bar

1 bar

$

Хотя оба файла — и foo, и bar — имеют длину в 10 Кбайт, файл bar занимает только 1 Кбайт дискового пространства, потому что остальные 9 Кбайт были пропущены seek(), когда файл был создан или записан.

 

11.2.5. Частичное чтение и запись

Хотя обе функции — и read(), и write() — принимают параметр, указывающий, сколько байт нужно прочитать или записать, ни одна из них не гарантирует, что обработает указанное количество байт, даже если не случается никаких ошибок. Простейший пример этого — попытки чтения из обычного файла, который уже позиционирован в конце. Система не может прочитать ни одного байта, но это в то же время не является ошибкой. Вместо этого read() возвращает 0 байт. Точно так же, если текущая позиция находилась в 10 байт от конца файла, и была выполнена попытка прочитать из файла более 10 байт, то прочитано будет ровно 10 байт и вызов read() вернет число 10. Опять-таки это не рассматривается как ошибочная ситуация.

Поведение read() также зависит от того, был ли файл открыт с флагом O_NONBLOCK. Для файлов многих типов O_NONBLOCK не влияет ни на что. Файлы, для которых система может гарантировать завершенность операции в пределах разумного периода времени, всегда блокирует чтение и запись; такие файлы часто называют быстрыми файлами. Это множество файлов включает локальные блочные устройства и обычные файлы. Для других типов файлов, таких как каналы, и символьных устройств вроде терминалов процесс может ожидать другого процесса (или человека), чтобы тот либо выполнил чтение, либо освободил ресурсы системы при обработке запроса на write(). В обоих случаях система не имеет способа знать — будет ли вообще возможно дождаться завершения системного вызова. Когда такие файлы открываются с флагом O_NONBLOCK, то для каждой операции с файлом система просто делает максимум того, что удается сделать немедленно, а затем возвращает управление вызывающему процессу.

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

Чтобы показать конкретный пример чтения и записи файлов, приведем простую реализацию cat. Она копирует стандартный поток ввода (stdin) на стандартный вывод (stdout) до тех пор, пока есть что копировать.

 1: /* cat.с */

 2:

 3: #include

 4: #include

 5:

 6: /* Пока есть данные на стандартном входе (fd0), копировать их в

 7:    стандартный выход (fd1). Выйти, когда не будет доступных данных. */

 8:

 9: int main(void) {

10:  char buf[1024];

11:  int len;

12:

13:  /* len будет >= 0, пока доступны данные

14:     и read() успешен */

15:  while ((len = read(STDIN_FILENO, buf, sizeof(buf))) > 0) {

16:   if (write(1, buf, len) != len) {

17:    perror("write");

18:    return 1;

19:   }

20:  }

21:

22:  /* len будет <= 0; если len = 0, больше нет

23:     доступных данных. Иначе - ошибка. */

24:  if (len < 0) {

25:   perror("read");

26:   return 1;

27:  }

28:

29:  return 0;

30: }

 

11.2.6. Сокращение файлов

Хотя обычные файлы автоматически растут при записи данных в их конец, у системы нет способа автоматически усекать файлы, когда данные в конце не нужны. К тому же, как система может узнать, что данные стали излишними? Это находится в компетенции процесса — извещать систему о том, когда файл можно сократить до определенной точки.

#include

int truncate(const char *pathname, size_t length);

int ftruncate(int fd, size_t length);

Размер файла устанавливается равным length, и все данные, находящиеся за новым концом файла, теряются.

Если length больше текущего размера файла, то файл увеличивается до заданного размера (по возможности используя "дырки"), хотя такое поведение и не гарантируется POSIX, поэтому на него нельзя полагаться при написании переносимых программ.

 

11.2.7. Синхронизация файлов

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

Есть несколько механизмов, которые может использовать приложение, чтобы дождаться записи данных на физический носитель. Флаг O_SYNC, описанный ранее в этой главе, при каждой операции записи в файл вызывает блокирование вызывающего процесса до тех пор, пока носитель не будет действительно обновлен. Хотя это, конечно, работает, все же такой подход не является достаточно аккуратным. Обычно приложения не нуждаются в том, чтобы все операции были синхронизированы, гораздо чаще они нуждаются в том, чтобы гарантировать, что некий набор операций завершился перед тем, как может быть начат другой набор операций. Системные вызовы fsync() и fdatasync() обеспечивают такую семантику.

#include

int fsync(int fd);

int fdatasync(int fd);

Оба системных вызова приостанавливают приложение до тех пор, пока в файл fd не будут записаны все данные, fsync() также ожидает обновления информации в inode файла, подобной времени доступа (информация inode для файлов перечислена в табл. 11.3). Однако ни один из этих вызовов не гарантирует записи на неразрушимое устройство хранения. Современные дисковые приводы имеют большие собственные кэши, поэтому сбой питания может привести к тому, что некоторые данные, сохраненные в кэше, будут потеряны.

 

11.2.8. Прочие операции

Файловая модель Linux достаточно хорошо поддерживает стандартизацию большинства файловых операций через обобщенные функции наподобие read() и write() (например, запись в программный канал выполняется так же, как запись в файл на диске). Однако некоторые устройства поддерживают операции, которые плохо моделируются такой абстракцией. Например, терминальные устройства, представленные как устройства символьные, нуждаются в представлении метода изменения скорости терминала, и приводы CD-ROM, представленные как блочные устройства, нуждаются в том, чтобы знать, кода они должны воспроизводить аудиодорожки, чтобы помочь увеличить производительность работы программистов.

Все эти разнообразные операции доступны через единственный системный вызов — ioctl() (сокращение для "I/O control" — управление вводом-выводом), прототип которого показан ниже.

#include

int ioctl(int fd, int request, ...);

Хотя часто он применяется следующим образом:

int ioctl (int fd, int request, void *arg);

Всякий раз когда используется ioctl(), его первый аргумент — это файл, с которым выполняются манипуляции, а второй аргумент указывает операцию, которая должна быть выполнена. Последний аргумент обычно представляет собой указатель на нечто, но на что именно, а так же точная семантика возвращаемого кода зависит от типа файла fd и типа запрошенной операции. Для некоторых операций arg — длинное целое вместо указателя; в этих случаях обычно применяется приведение типов. В нашей книге есть множество примеров применения ioctl(), и вам нет нужды заботиться об ioctl() до тех пор, пока вы не доберетесь до них.

 

11.3.1. Поиск информации inode

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

#include

int stat(const char *pathname, struct stat *statbuf);

int lstat (const char *pathname, struct stat *statbuf);

int fstat(int fd, struct stat *statbuf);

Первая версия, stat() возвращает информацию inode для файла, на который осуществляется ссылка через pathname, следуя всем символическим ссылкам, которые она представляет. Если вы не хотите следовать символическим ссылкам (например, чтобы проверить, не является ли само имя такой ссылкой), то используйте вместо этого lstat(). Последняя версия, fstat(), возвращает inode, на который ссылается текущий открытый файловый дескриптор. Все три системных вызова заполняют структуру struct stat, на которую указывает параметр statbuf, информацией о файловом inode. В табл. 11.3 описана информация, доступная в struct stat.

Таблица 11.3. Члены структуры struct stat

 

11.3.2. Простой пример

stat()

Рассмотрим простую программу, которая отображает информацию из lstat() для каждого имени файла, переданного в аргументе. Она иллюстрирует, как использовать значения, возвращенные семейством функций stat().

 1: /* statsamp.с */

 2:

 3: /* Для каждого имени файла, переданного в командной строке, отображаем

 4:    всю информацию, которую возвращает lstat() для файла. */

 5:

 6: #include

 7: #include

 8: #include

 9: #include

10: #include

11: #include

12: #include

13: #include

14:

15: #define TIME_STRING_BUF 50

16:

17: /* Пользователь передает buf (минимальной длины TIME_STRING_BUF) вместо

18:    использования статического для функции буфера, чтобы избежать применения

19:    локальных статических переменных и динамической памяти. Никаких ошибок

20:    происходить не должно, поэтому никакой проверки ошибок не делаем. */

21: char *time String (time_t t, char *buf) {

22:  struct tm *local;

23:

24:  local = localtime(&t);

25:  strftime(buf, TIME_STRING_BUF, "%c", local);

26:

27:  return buf;

28: }

29:

30: /* Отобразить всю информацию, полученную от lstat() по имени

31:    файла как единственному параметру. */

32: int statFile(const char *file) {

33:  struct stat statbuf;

34:  char timeBuf[TIME_STRING_BUF];

35:

36:  if (lstat(file, &statbuf)) {

37:   fprintf(stderr, "не удалось lstat %s: %s\n", file,

38:    strerror(errno));

39:   return 1;

40:  }

41:

42:  printf("Имя файла : %s\n", file);

43:  printf("На устройстве: старший %d/младший %d Inode номер: %ld\n" ,

44:   major(statbuf.st_dev), minor(statbuf.st_dev),

45:   statbuf.st_ino);

46:  printf ("Размер : %-101d Тип: %07o"

47:   "Права доступа : %05o\n", statbuf.st_size,

48:   statbuf.st_mode & S_IFMT, statbuf.st_mode &~(S_IFMT));

49:  printf("Владелец : %d Группа : %d"

50:   " Количество ссылок : %d\n",

51:   statbuf.st_uid, statbuf.st_gid, statbuf.st_nlink);

52:  printf("Время создания : %s\n",

53:   timeString(statbuf.st_ctime, timeBuf));

54:  printf("Время модификации : %s\n",

55:   timeString(statbuf.st_mtime, timeBuf));

56:  printf("Время доступа : %s\n",

57:   timeString (statbuf.st_atime, timeBuf));

58:

59:  return 0;

60: }

61:

62: int main(int argc, const char **argv) {

63:  int i;

64:  int rc = 0 ;

65:

66:  /* Вызвать statFile() для каждого имени файла,

67:     переданного в командной строке. */

68:  for (i = 1; i < argc; i++) {

69:   /* Если statFile() сбоит, rc будет содержать не ноль.*/

70:   rc |= statFile(argv[i]);

71:

72:   /* это печатает пробел между позициями,

73:      но не за последней */

74:   if ((argc - i) > 1) printf ("\n");

75:  }

76:

77:  return rc;

78: }

 

11.3.3. Простое определение прав доступа

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

#include

int access(const char *pathname, int mode);

mode — это маска, которая содержит одно или более перечисленных ниже значений.

access() возвращает 0, если указанный режим доступа разрешен, в противном случае возвращает ошибку EACCESS.

 

11.3.4. Изменение прав доступа к файлу

Права доступа и модификаторы прав доступа к файлу изменяются с помощью системного вызова chmod().

#include

int chmod(const char *pathname, mode_t mode);

int fchmod(int fd, mode_t mode);

Хотя chmod() позволяет указать путь, помните, что права доступа к файлу определяет inode, а не имя файла. Если у файла есть множество жестких ссылок, то изменение прав доступа по одному из имен файла изменяет права доступа к нему везде, где он встречается в файловой системе. Параметр mode может быть любой комбинацией прав доступа и модификаторов прав доступа, объединенных по логическому "И". Хотя это достаточно нормально — специфицировать по несколько этих значений за раз, общей практикой для программ является указание новых прав доступа непосредственно в восьмеричном виде. Только пользователь root и владелец файла могут изменять права доступа к файлу — все остальные, кто попытается это сделать, получат ошибку EPERM.

 

11.3.5. Смена владельца и группы файла

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

#include

int chown(const char *pathname, uid_t owner, gid_t group);

int fchown(int fd, uid_t owner, gid_t group);

Параметры owner и group указывают нового владельца и группу для файла. Если любой из них равен -1, соответствующее значение не изменяется. Только пользователь root имеет право сменить владельца файла. Когда владелец файла меняется или файл записывается, то бит setuid для этого файла всегда очищается из соображений безопасности. Как root, так и владелец файла могут менять группу, которая владеет файлом, но при условии, что владелец сам является членом этой группы. Если у файла установлен бит выполнения для группы, то бит setgid очищается из тех же соображений безопасности. Если же бит выполнения для группы не установлен, то у файла включена принудительная блокировка и режим предохраняется.

 

11.3.6. Изменение временных меток файла

Владелец файла может изменять mtime и atime файла на любое желаемое значение. Это делает такие метки бесполезными для целей аудита, но позволяет инструментам архивирования вроде tar и cpio сбрасывать временные метки файлов в то значение, когда они были архивированы. Метка ctime изменяется, когда обновляются mtime и atime, поэтому tar и cpio не могут восстановить их.

Существуют два способа изменения этих меток: utime() и utimes(). utime() появилась в System V, после чего была адаптирована POSIX, в то время как utimes() пришла из BSD. Обе функции эквивалентны; они отличаются только способом, каким указываются новые временные метки.

#include

int utime(const char *pathname, struct utimbuf *buf);

#include

int utimes(const char *pathname, struct timeval *tvp);

Версия POSIX, utime(), принимает struct utimbuf, которая определена в , как показано ниже.

struct utimbuf {

 time_t асtime;

 time_t modtime;

};

utimes() из BSD вместо этого передает новое значение atime и mtime через struct timeval, которая определена в .

struct timeval {

 long tv_sec;

 long tv_usec;

};

Элемент tv_sec содержит новое значение atime; tv_usec содержит новое значение mtime для utimes().

Если каждой из функций вторым параметром передать NULL, то обе временные метки должны быть установлены в текущее время. Новые значения atime и mtime устанавливаются в секундах, прошедших с начала эры (так же, как значение, возвращаемое time()), как определено в главе 18.

 

11.3.7. Расширенные атрибуты Ext3

Главная файловая система, используемая в Linux — это Third Extended File System (третья расширенная файловая система), обычно упоминаемая как ext3. Хотя она поддерживает все традиционные функциональные средства файловых систем Unix, такие как значение отдельных бит в режиме файла, она также позволяет хранить некоторые дополнительные атрибуты для каждого файла. В табл. 11.4 описаны поддерживаемые в настоящее время дополнительные атрибуты. Эти флаги могут быть установлены и просмотрены с помощью программ chattr и lsattr.

Таблица 11.4. Расширенные атрибуты файла

Поскольку расширенные атрибуты ext3 выходят за пределы стандартного интерфейса файловых систем, они не могут модифицироваться с помощью chmod(), как все остальные атрибуты. Вместо этого используется ioctl(). Вспомним, как определен вызов ioctl().

#include

#include

int ioctl(int fd, int request, void *arg);

Файл, атрибуты которого меняются, должен быть открыт, как для fchmod(). Запрос (параметр request) на получение текущего состояния флагов — EXT3_IOC_GETFLAGS, а для установки их — EXT3_IOC_SETFLAGS. В обоих случаях arg должен быть указателем на int. Если используется EXT3_IOC_GETFLAGS, то long устанавливается в текущее значение программных флагов. Если применяется EXT3_IOC_SETFLAGS, то новое значение файловых флагов берется из int, на который указывает arg.

Это дополнение и неизменяемые флаги могут быть изменены только пользователем root, поскольку это связано с операциями, которые может выполнять только root.

Другие флаги могут быть модифицированы либо пользователем root, либо владельцем файла.

Приведем пример небольшой программы, которая отображает флаги для любого файла, переданного в командной строке. Она работает только с файлами из файловой системы ext3. Вызов ioctl() завершится неудачей, если применить его к файлам из любой другой файловой системы.

 1: /* checkflags.c */

 2:

 3: /* Для каждого имени файла, переданного в командной строке, отобразить

 4:    информацию об атрибутах этого файла в файловой системе ext3. */

 5:

 6: #include

 7: #include

 8: #include

 9: #include

10: #include

11: #include

12: #include

13:

14: int main(int argc, const char **argv) {

15:  const char **filename = argv + 1;

16:  int fd;

17:  int flags;

18:

19:  /* Пройти по каждому имени файла, переданному в командной строке. Последний

20:     указатель в argv[] равен NULL, поэтому такие циклы while() корректны. */

21:  while(*filename) {

22:   /* В отличие от нормальных атрибутов, атрибута ext3 можно опрашивать только

23:      если есть файловый дескриптор (имя файла не годится).

24:      Для выполнения запроса атрибутов ext3 нам не нужен доступ на запись,

25:      поэтому O_RDONLY подойдет. */

26:   fd = open(*filename, O_RDONLY);

27:   if (fd<0) {

28:    fprintf(stderr, "не открывается %s: %s\n", *filename,

29:     strerror(errno));

30:    return 1;

31:   }

32:

33:   /* Этот вызов получает атрибуты, и помещает их в flags */

34:   if (ioctl(fd, EXT3_IOC_GETFLAGS, &flags)) {

35:    fprintf(stderr, "ioctl завершился ошибкой на %s: %s\n", *filename,

36:     strerror(errno));

37:    return 1;

38:   }

39:

40:   printf("%s: ", *filename++);

41:

42:   /* Проверить каждый атрибут, и отобразить сообщение для каждого,

43:      который включен. */

44:   if (flags & EXT3_APPEND_FL) printf("Append");

45:   if (flags & EXT3_IMMUTABLE_FL) printf("Immutable");

46:   if (flags & EXT3_SYNC_FL) printf("Sync");

47:   if (flags & EXT3_NODUMP_FL) printf("Nodump");

48:

49:   printf("\n");

50:   close(fd);

51:  }

52:

53:  return 0;

54: }

Ниже приведена похожая программа, которая устанавливает расширенные атрибуты ext3 для указанного списка файлов. Первый параметр должен быть списком флагов, которые нужно установить. Каждый флаг представляется в списке в виде одной буквы: А — только для добавления (append only), I — неизменяемый (immutable), S — синхронизированный (sync), N — недампированный (nodump). Эта программа не модифицирует существующие флаги файла; она только устанавливает флаги, переданные в командной строке.

 1: /* setflags.c */

 2:

 3: /* Первый параметр этой программы — строка, состоящая из

 4:    0 (допускается пустая) или более букв из набора I, A, S,

 5:    N. Эта строка указывает, какие из атрибутов ext3 должны

 6:    быть включены для файлов, указанных в остальных

 7:    параметрах командной строки — остальные атрибуты выключаются

 8:    буквы обозначают соответственно: immutable, append-only, sync и nodump.

 9:

10:    Например, команда "setflags IN file1, file2" включает

11:    флаги immutable и nodump для файлов file1 и file2, но отключает

12:    флаги sync и append-only для этих файлов. */

13:

14: #include

15: #include

16: #include

17: #include

18: #include

19: #include

20: #include

21:

22: int main(int argc, const char **argv) {

23:  const char **filename = argv + 1;

24:  int fd;

25:  int flags = 0;

26:

27:  /* Убедиться, что указаны устанавливаемые флаги, вместе

28:     с именами файлов. Позволить установить "0", как признак

29:     того, что все флаги должны быть сброшены. */

30:  if (argc<3){

31:   fprintf(stderr, "Использование setflags: [0][I][A][S][N]"

32:    "\n");

33:   return 1;

34:  }

35:

36:  /* каждая буква представляет флаг; установить

37:     флаг, которые указаны */

38:  if (strchr(argv[1], 'I') ) flags |= EXT3_IMMUTABLE_FL;

39:  if (strchr(argv[1], 'A') ) flags |= EXT3_APPEND_FL;

40:  if (strchr(argv[1], 'S') ) flags |= EXT3_SYNC_FL;

41:  if (strchr(argv[1], 'N') ) flags |= EXT3_NODUMP_FL;

42:

43:  /* пройти по всем именам в argv[] */

44:  while (*(++filename)) {

45:   /* В отличие от нормальных атрибутов, атрибута ext3 можно опрашивать,

46:      только если есть файловый дескриптор (имя файла не годится).

47:      Для выполнения запроса атрибутов ext3 нам не нужен доступ на запись,

48:      поэтому O_RDONLY подойдет. */

49:   fd = open(*filename, O_RDONLY);

50:   if (fd < 0) {

51:    fprintf(stderr, "невозможно открыть %s:%s\n", *filename,

52:     strerror(errno));

53:    return 1;

54:   }

55:

56:   /* Установить атрибуты в соответствии с переданными

57:      флагами. */

58:   if (ioctl(fd, EXT3_IOC_SETFLAGS, &flags)) {

59:    fprintf(stderr, "Сбой ioctl в %s:%s\n", *filename,

60:     strerror(errno));

61:    return 1;

62:   }

63:   close(fd);

64:  }

65:

66:  return 0;

67: }

 

Вспомните, что компоненты каталогов (имена файлов) — это ни что иное, как указатели на дисковые информационные узлы (on-disk inodes); почти вся важная информация, касающаяся файла, хранится в его inode. Вызов open() позволяет процессу создавать компоненты каталогов, которые являются обычными файлами, но для создания файлов других типов и для манипулирования компонентами каталогов могут понадобиться другие функции. Функции, которые позволяют создавать, удалять и выполнять поиск каталогов, описаны в главе 14; файлы сокетов — в главе 17. В настоящем разделе раскрываются символические ссылки, файлы устройств и FIFO.

 

11.4.1. Создание входных точек устройств и именованных каналов

Процессы создают файлы устройств и именованных каналов в файловой системе с помощью вызова mknod().

#include

#include

int mknod(const char *pathname, mode_t mode, dev_t dev);

pathname — это имя файла, который нужно создать, mode — это и режим доступа (который модифицируется текущим umask), и тип нового файла (S_IFIFO, S_IFBLK, S_IFCHR). Последний параметр, dev, содержит старший (major) и младший (minor) номера создаваемого устройства. Тип устройства (символьное или блочное) и старший номер устройства сообщают ядру, какой драйвер устройств отвечает за операции с этим файлом устройства. Младший номер используется внутри драйвером устройства, чтобы различать отдельные устройства среди многих, которыми он управляет. Только пользователю root разрешено создавать файлы устройств; именованные же каналы могут создавать все пользователи.

Заголовочный файл представляет три макроса для манипулирования значениями типа dev_t. Макрос makedev() принимает старшие номера в первом аргументе, младшие — во втором и возвращает значение dev_t, ожидаемое mknod(). Макросы major() и minor() принимают значение типа dev_t в качестве единственного аргумента и возвращают, соответственно, старший и младший номер устройства.

Программа mknod, доступная в Linux, предоставляет пользовательский интерфейс к системному вызову mknod() (подробности см. в man 1 mknod). Ниже приведена упрощенная реализация mknod для иллюстрации системного вызова mknod(). Следует отметить, что программа создает файл с режимом доступа 0666 (предоставляя право на чтение и запись всем пользователям) и зависит от системной установки umask процесса для получения прав доступа.

 1: /* mknod.с */

 2:

 3: /* Создать устройство или именованный канал, указанный в командной строке.

 4:    См. подробности о параметрах командной строки

 5:    на man-странице mknod(1). */

 6:

 7: #include

 8: #include

 9: #include

10: #include

11: #include

12: #include

13: #include

14:

15: void usage(void) {

16:  fprintf (stderr, "использование: mknod <путь> [b | с | u | p]"

17:   "<старший> <младший>\n");

18:  exit(1);

19: }

20:

21: int main(int argc, const char **argv) {

22:  int major = 0, minor = 0;

23:  const char *path;

24:  int mode = 0666;

25:  char *end;

26:  int args;

27:

28:  /* Всегда необходимы, как минимум, тип создаваемого inode

29:     и путь к нему. */

30:  if (argc < 3) usage();

31:

32:  path = argv[1];

33:

34:  /* второй аргумент указывает тип создаваемого узла */

35:  if (!strcmp(argv[2], "b")) {

36:   mode | = S_IFBLK;

37:   args = 5;

38:  } else if (!strcmp(argv[2] , "с") || !strcmp(argv[2], "u")) {

39:   mode |= S_IFCHR;

40:   args = 5;

41:  } else if(!strcmp(argv[2], "p")) {

42:   mode |= S_IFIFO;

43:   args = 3;

44:  } else {

45:   fprintf(stderr, "неизвестный тип узла %s\n", argv[2]);

46:   return 1;

47:  }

48:

49:  /* args сообщает, сколько аргументов ожидается, поскольку нам нужно

50:    больше информации при создания устройств, чем именованных каналов*/

51:  if (argc != args) usage();

52:

53:  if (args == 5) {

54:   /* получить старший и младший номера файла устройств,

55:      который нужно создать */

56:   major = strtol(argv[3], &end, 0);

57:   if (*end) {

58:    fprintf(stderr,"неверный старший номер %s\n", argv[3]);

59:    return 1;

60:   }

61:

62:   minor = strtol(argv[4], &end, 0);

63:   if (*end) {

64:    fprintf(stderr, "неверный младший номер %s\n", argv[4]);

65:    return 1;

66:   }

67:  }

68:

69:  /* если создается именованный канал, то финальный параметр

70:     игнорируется */

71:  if (mknod(path, mode, makedev(major, minor))) {

72:   fprintf(stderr, "вызов mknod не удался : %s\n", strerror(errno));

73:   return 1;

74:  }

75:

76:  return 0;

77: }

 

11.4.2. Создание жестких ссылок

Когда множество имен файлов в файловой системе ссылаются на единственный inode, такие файлы называют жесткими ссылками (hard links) на него. Все эти имена должны располагаться на одном физическом носителе (обычно это значит, что они должны быть на одном устройстве). Когда файл имеет множество жестких ссылок, все они равны — нет способа узнать, с каким именем первоначально был создан файл. Одно из преимуществ такой модели заключается в том, что удаление одной жесткой ссылки не удаляет файл с устройства — он остается до тех пор, пока все ссылки на него не будут удалены. Системный вызов link() связывает новое имя файла с существующим inode.

#include

int link(const char *origpath, const char *newpath);

Параметр origpath ссылается на существующее путевое имя, a newpath представляет собой путь для новой жесткой ссылки. Любой пользователь может создавать ссылку на файл, к которому у него есть доступ по чтению, до тех пор, пока он имеет право записи в каталоге, в котором ссылка создается, и право выполнения в каталоге, в котором находится origpath. Только пользователь root имеет право создавать жесткие ссылки на каталоги, но поступать так — обычно плохая идея, поскольку большинство файловых систем и некоторые утилиты не работают с ними достаточно хорошо — они полностью их отвергают.

 

11.4.3. Использование символических ссылок

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

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

• chown()

• lstat()

• readlink()

• rename()

• unlink()

Символически ссылки создаются почти так же, как жесткие, но при этом используется системный вызов symlink().

#include

int symlink(const char *origpath, const char *newpath);

Если вызов успешен, создается файл newpath как символическая ссылка, указывающая на oldpath (часто говорят, что newpath содержит в качестве своего значения oldpath).

Поиск значения символической ссылки немного сложнее.

#include

int readlink(const char *pathname, char *buf, size_t bufsiz);

Буфер, на который указывает buf, наполняется содержимым символической ссылки pathname до тех пор, пока хватает длины buf, указанной в bufsize в байтах. Обычно константы PATH_MAX применяется в качестве размера буфера, поскольку она должна быть достаточно большой, чтобы уместить содержимое любой символической ссылки. Одна странность функции readlink() связана с тем, что она не завершает строку, которую записывает в buf, символом '\0', поэтому buf не содержит корректную строку С, даже если readlink() выполняется успешно. Вместо этого она возвращает количество байт, записанных в buf в случае успеха и -1 — при неудаче. Из-за этой особенности код, использующий readlink(), часто выглядит так, как показано ниже.

char buf[PATH_MAX + 1];

int bytes;

if ( (bytes = readlink (pathname, buf, sizeof (buf) - 1)) < 0) {

 perror("ошибка в readlink");

} else {

 buf[bytes]= '\0';

}

 

11.4.4. Удаление файлов

Удаление файла — это удаление указателя на его inode и удаление содержимого файла, если не остается ни одой жесткой ссылки на него. Если любой процесс держит файл открытым, то inode этого файла предохраняется до тех пор, пока финальный процесс не закроет его, после чего и inode, и содержимое файла уничтожаются. Поскольку нет способа принудительно удалить файл немедленно, эта операция называется разъединением (unlinking) файла, поскольку она удаляет связь между именем файла и inode.

#include

int unlink(char *pathname);

 

11.4.5. Переименование файлов

Имя файла может быть изменено на любое другое до тех пор, пока оба имени относятся к одному и тому же физическому носителю (это то же ограничение, что и касается создания жестких ссылок). Если новое имя уже ссылается на файл, то такое имя разъединяется перед тем, как произойдет переименование. Атомарность системного вызова rename() гарантируется. Другие процессы в системе всегда видят существование файла под тем или иным именем, но не под обеими сразу. Поскольку открытые файлы не связаны с именами (а только с inode), то переименование файла, который открыт в других процессах, никак не влияет на их работу. Ниже показано, как выглядит системный вызов для переименования файлов.

#include

int rename(const char *oldpath, const char *newpath);

После вызова файл, на который ссылалось имя oldpath, получает ссылку newpath вместо oldpath.

 

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

#include

int fcntl (int fd, int command, long arg);

Для многих команд arg не используется. Ниже мы обсудим большую часть применений fcntl(). Этот вызов используется для блокировки файлов, аренды файлов, неблокирующего ввода-вывода, который рассматривается в главе 13, а также уведомления об изменениях каталогов, представленного в главе 14.

 

11.5.1. Изменение режима доступа к открытому файлу

Режим добавления (указываемый флагом O_APPEND при открытии файла) и неблокирующий режим (флаг O_NONBLOCK), могут быть включены и отключены уже после того, как файл был открыт, с помощью команды F_SETFL в fcntl(). Параметр arg при этом должен содержать флаги, которые нужно установить — если какой-то из флагов не указан для fd, он отключается.

F_GETFL можно использовать для запроса текущих установленных флагов файла. Это возвращает все флаги, включая режим чтения/записи для открытого файла. F_SETFL позволяет только устанавливать упомянутые выше флаги — любые другие флаги, представленные в аргументе arg, игнорируются.

fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | O_RDONLY);

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

fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | O_APPEND);

Следует отметить, что это предохраняет установку O_NONBLOCK. Отключение режима добавления выглядит похоже.

fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) & ~O_APPEND);

 

11.5.2. Модификация флага "закрыть при выполнении"

Во время системного вызова exec() дескрипторы файлов обычно остаются открытыми для использования в новых программах. В некоторых случаях может потребоваться, чтобы файлы закрывались, когда вызывается exec(). Вместо закрытия их вручную вы можете попросить систему закрыть соответствующий файловый дескриптор при вызове exec() с помощью команд F_GETFD и F_SETFD в fcntl(). Если флаг "закрыть при выполнении" (close-on-exec) установлен, когда применяется F_GETFD, возвращается ненулевое значение, в противном случае возвращается ноль. Флаг "закрыть при выполнении" устанавливается командой F_SETFD; он отключается, если arg равно 0, в противном случае он включается.

Ниже показано, как можно заставить fd закрываться, когда процесс вызывает exec().

fcntl(fd, F_SETFD, 1);

 

11.5.3. Дублирование файловых дескрипторов

Иногда процессам требуется создать новый файловый дескриптор, который ссылается на ранее открытый файл. Командные оболочки используют эту функциональность для перенаправления стандартного ввода, вывода и потока ошибок по запросу пользователя. Если процессу не важно, какой файловый дескриптор будет использован для новой ссылки, он должен использовать dup().

#include

int dup(int oldfd);

dup() возвращает файловый дескриптор, который ссылается на тот же inode, что и oldfd, или -1 в случае ошибки, oldfd остается корректным дескриптором, по-прежнему ссылающимся на исходный файл. Новый файловый дескриптор — это всегда наименьший доступный файловый дескриптор. Если процессу нужно получить новый файловый дескриптор с определенным значением (например, 0, чтобы перенаправить стандартный ввод), то он должен использовать dup2().

#include

int dup2(int oldfd, int newfd);

Если newfd ссылается на уже открытый дескриптор, то он закрывается. Если вызов завершен успешно, он возвращает новый файловый дескриптор и newfd ссылается на тот же файл, что oldfd. Системный вызов fcntl() представляет почти ту же функциональность командой F_DUPFD. Первый аргумент — fd — это уже открытый файловый дескриптор. Новый файловый дескриптор — это первый доступный дескриптор, равный или больший, чем значение последнего аргумента fcntl(). (В этом состоит отличие от работы dup2().) Вы можете реализовать dup2() через fcntl() следующим образом.

int dup2(int oldfd, int newfd) {

 close(newfd); /* ensure new fd is available */

 return fcntl(oldfd, F_DUPFD, newfd);

}

Создание двух файловых дескрипторов, ссылающихся на один и тот же файл — это не то же самое, что открытие файла дважды. Почти все атрибуты дублированных дескрипторов разделяются: они разделяют текущую позицию, режим доступа и блокировки. (Все это записывается в файловой структуре, которая создается при каждом открытии файла. Файловый дескриптор ссылается на файловую структуру, и дескриптор, возвращенный dup(), ссылается на одну и ту же структуру.) Единственный атрибут, который может независимо управляться в этих двух дескрипторах — это состояние "закрыть при выполнении". После того, как процесс вызывает fork(), то файлы, открытые в родительском процессе, наследуются дочерним, и эти пары файловых дескрипторов (один в родительском процессе, другой — в дочернем) ведут себя так, будто файловые дескрипторы были дублированы с текущей позицией и другими разделенными атрибутами.

 

Теперь, когда мы рассмотрели основные манипуляции с файлами, мы можем научить ladsh перенаправлению ввода и вывода через файлы и каналы. ladsh2.с, который мы представим здесь, работает с каналами (описанными символом | в командах ladsh, как это делается в большинстве командных оболочек) и перенаправление ввода и вывода в файловые дескрипторы. Мы покажем только модифицированные части кода здесь — полный исходный текст ladsh2.с доступен по упомянутым в начале книги адресам. Изменения в parseCommand() — это простое упражнение по разбору строк, поэтому мы не будем надоедать дискуссией об этом.

 

11.7.1. Структуры данных

Хотя код в ladsh1.с поддерживает концепцию задания как множества процессов (предположительно, объединенных вместе каналами), он не предоставляет способа указания того, какие файлы использовать для ввода и вывода. Чтобы позволить это, добавляются новые структуры данных и модифицируются существующие.

24:  REDIRECT_APPEND};

25:

26: struct redirectionSpecifier {

27:  enum redirectionTypetype; /* тип перенаправления */

28:  int fd; /*перенаправляемый файловый дескриптор*/

29:  char * filename; /* файл для перенаправления fd */

30: };

31:

32: struct childProgram {

33:  pid_t pid; /* 0 если завершен */

34:  char **argv; /* имя программы и аргументы */

35:  int numRedirections; /* элементы в массиве перенаправлений */

36:  struct redirectionSpecifier *redirections; /* перенаправления ввода-вывода*/

37: } ;

Структура struct redirectionSpecifier сообщает ladsh2.с о том, как установить отдельный файловый дескриптор. Она содержит enum redirectionTypetype, который указывает, является ли это перенаправление перенаправлением ввода, перенаправлением вывода, который должен быть добавлен к существующему файлу, либо перенаправлением вывода, которое заменяет существующий файл. Она также включает перенаправляемый файловый дескриптор и имя файла. Каждая дочерняя программа (struct childProgram) теперь специфицирует нужное ей количество перенаправлений.

Эти новые структуры данных не связаны с установкой каналов между процессами. Поскольку задание определено как множество дочерних процессов с каналами, связывающими их, нет необходимости в более подробной информации, описывающей каналы. На рис. 11.1 показано, как эти новые структуры должны выглядеть для команды tail < input-file | sort > output-file.

Рис. 11.1. Структуры данных, описывающие задание для ladsh2.с

 

11.7.2. Изменения в коде

Как только в parseCommand() будут правильно отражены структуры данных, то запуск команд в правильном порядке становится довольно простым при достаточном внимании к деталям. Прежде всего, мы добавляем цикл в parseCommand() для запуска дочерних процессов, поскольку теперь их может быть множество. Прежде чем войти в цикл, мы устанавливаем nextin и nextout, которые являются файловыми дескрипторами, используемыми в качестве стандартных потоков ввод и вывода для следующего запускаемого процесса. Для начала мы используем те же stdin и stdout, что и оболочка.

Теперь посмотрим, что происходит внутри цикла. Основная идея описана ниже.

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

2. Породить новый процесс. Внутри дочернего перенаправить stdin и stdout, как указано с помощью nextin, nextout и всех специфицированных ранее перенаправлений.

3. Вернувшись обратно в родительский процесс, закрыть nextin и nextout, используемые только что запущенным дочерним процессом (если только они не являются потоками ввода и вывода самой оболочки).

4. Теперь настроить следующий процесс в задании для приема его ввода из вывода процесса, который мы только что создали (через nextin).

Вот как эти идеи перевести на С.

365: nextin=0, nextout=1;

366: for (i=0; i

367:  if ((i+1) < newJob.numProgs) {

368:   pipe(pipefds);

369:   nextout = pipefds[1];

370:   } else {

371:    nextout = 1;

372:   }

373:

374:   if (!(newJob.progs[i].pid = fork())) {

375:    if (nextin != 0) {

376:     dup2(nextin, 0);

377:     close(nextin);

378:    }

379:

380:    if (nextout != 1) {

381:     dup2(nextout, 1);

382:     close(nextout);

383:    }

384:

385:    /* явное перенаправление перекрывает каналы */

386:    setupRedirections(newJob.progs+i);

387:

388:    execvp(newJob.progs[i].argv[0], newJob.progs[i].argv);

389:    fprintf(stderr, "exec() of %s failed: %s\n",

390:     newJob.progs[i].argv[0],

391:    strerror(errno));

392:    exit(1);

393:   }

394:

395:   /* поместить наш дочерний процесс в группу процессов,

396:      чей лидер - первый процесс канала */

397:   setpgid(newJob.progs[i].pid, newJob.progs[0].pid);

398:

399:   if (nextin != 0) close(nextin);

400:   if (nextout != 1) close (nextout);

401:

402:   /* Если больше нет процессов, то nextin - мусор,

403:      но это не имеет значения */

404:   nextin = pipefds[0];

Единственный код, добавленный в ladsh2.с для обеспечения перенаправлений — это функция setupRedirections(), код которой останется неизменным во всех последующих версиях ladsh. Ее задача состоит в обработке спецификаторов struct redirectionSpecifier для дочерних заданий и соответствующей модификации дочерних файловых дескрипторов. Мы рекомендуем просмотреть код этой функции в приложении Б.

 

12.1.1. Жизненный цикл сигнала

Сигналы имеют четко определенный жизненный цикл: они создаются, сохраняются до тех пор, пока ядро не выполнит определенное действие на основе сигнала, а затем вызывают совершение этого действия. Создание сигнала называют по-разному: поднятие (raising), генерация или посылка сигнала. Обычно процесс посылает сигнал другому процессу, в то время как ядро генерирует сигналы для отправки процессу. Когда процесс посылает сигнал самому себе, говорят, что он поднимает его. Однако эти термины используются не особо согласованно.

Между временем, когда сигнал отправлен и тем, когда он вызывает какое-то действие, его называют ожидающим (pending). Это значит, что ядро знает, что сигнал должен быть обработан, но пока не имеет возможности сделать это. Как только сигнал поступает в процесс назначения, он называется доставленным. Если доставленный сигнал вызывает выполнение специального фрагмента кода (имеется в виду обработчик сигнала), то такой сигнал считается перехваченным. Есть разные способы, которыми процесс может предотвратить асинхронную доставку сигнала, но все же обработать его (например, с помощью системного вызова sigwait()). Когда такое случается, сигнал называют принятым.

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

 

12.1.2. Простые сигналы

Изначально обработка сигналов была проста. Системный вызов signal() использовался для того, чтобы сообщить ядру, как доставить процессу определенный сигнал.

#include

void * signal(int signum, void *handler);

Здесь signum — это сигнал, который нужно обработать, a handler определяет действия, которое должно быть выполнено при доставке сигнала. Обычно handler — это указатель на функцию-обработчик сигнала, которая не принимает параметров и не возвращает значения. Когда сигнал доставлен процессу, ядро как можно скорее запускает функцию-обработчик. Когда функция возвращает управление, ядро возобновляет выполнение процесса с того места, где он был прерван. Системные инженеры распознают в этом механизме обработки сигналов аналог доставки аппаратных прерываний. Прерывания и сигналы очень похожи и у них возникают сходные проблемы.

Доступно множество номеров сигналов. В табл. 12.1 перечислены все сигналы, поддерживаемые в настоящее время Linux, за исключением сигналов реального времени. Они имеют символические имена, начинающиеся с SIG, и мы будем использовать SIG ЧТО-ТО , говоря о каком-то из них.

Параметр handler может иметь два специальных значения — SIG_IGN и SIG_DFL (оба определены в ). Если указано SIG_IGN, сигнал игнорируется, SIG_DFL сообщает ядру, что нужно выполнить действие по умолчанию, как правило, уничтожив процесс либо проигнорировав сигнал. Два сигнала — SIGKILL и SIGSTOP — не могут быть перехвачены. Ядро всегда выполняет действие по умолчанию для этих сигналов, соответственно, уничтожая процесс и приостанавливая его.

Функция signal() возвращает предыдущий обработчик сигнала (который мог быть SIG_IGN или SIG_DFL). Обработчики сигналов резервируются при создании новых процессов вызовом fork(), и все сигналы, которые установлены в SIG_IGN, игнорируются и после вызова exec(). Все не игнорируемые сигналы после exec() устанавливаются в SIG_DFL.

Все это выглядит достаточно простым, пока вы не спросите себя: что произойдет, если сигнал SIG ЧТО-ТО будет отправлен процессу, который уже исполняет обработчик сигнала для SIG ЧТО-ТО .

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

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

Сложность написания реентерабельных обработчиков сигналов — это главная причина того, почему ядро не доставляет сигнал процессу, который уже его обрабатывает. Такая модель также затрудняет процессам возможность обрабатывать большое количество сигналов, поступающих ему слишком быстро. Как только сигнал осуществляет новый вызов обработчика, стек процесса растет безо всякого предела, пренебрегая правильным поведением самой программы.

Первое решение этой проблемы было неудачным. Прежде чем вызывается обработчик сигнала, для программы значение этого обработчика устанавливалось в SIG_DFL, и ожидалось, что правильное его значение будет восстановлено немедленно, как только возможно. Хотя это упрощало написание обработчиков сигналов, но также делало невозможным для программиста обрабатывать сигналы надежным образом. Если два экземпляра одного и того же сигнала поступали быстро друг за другом, то ядро обрабатывало второй из них способом, принятым по умолчанию. Это означало, что сигнал, пришедший вторым, игнорировался (и пропадал навсегда), или же процесс прерывался. Эта реализация известна под названием ненадежных сигналов, потому что не позволяла написать обработчики, ведущие себя надежным, правильным образом.

К сожалению, именно такая модель сигналов используется в ANSI/ISO-стандарте С. Хотя программные интерфейсы надежных сигналов, в которых исправлен этот недостаток, уже широко распространены, стандартизация ненадежных сигналов в ANSI/ISO, видимо, останется навсегда.

 

12.1.3. Надежные сигналы

Реализация BSD для решения проблемы множества сигналов полагается на простое ожидание завершения работы каждого обработчика сигналов в процессе перед доставкой следующего. Это гарантирует то, что каждый сигнал будет рано или поздно обработан, а также исключает риск переполнения стека. Вспомним, что когда ядро удерживает сигнал для отложенной доставки, сигнал называется ожидающим (pending).

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

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

Хотя BSD представляет адаптированную версию модели сигналов POSIX, комитет по стандартизации POSIX упростил ее для системных вызовов, с тем чтобы модифицировать диспозицию групп сигналов, предлагая новые системные вызовы для оперирования наборами сигналов. Наборы сигналов представлены типом данных sigset_t, и для манипулирования ими предусмотрен набор макросов.

 

12.1.4. Сигналы и системные вызовы

Часто сигналы доставляются процессу, который находится состоянии ожидания наступления некоторого внешнего события. Например, текстовый редактор часто ожидает завершения read(), чтобы возвратить ввод терминала. Когда системный администратор посылает процессу сигнал SIGTERM (нормальный сигнал, посылаемый командой kill, позволяющий процессу завершиться чисто), то процесс может обработать его, как описано ниже.

1. Не пытаться перехватить сигнал и быть прерванным ядром (обработка SIGTERM по умолчанию). Это оставляет пользовательский терминал в нестандартной конфигурации, затрудняя ему продолжение работы.

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

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

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

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

Обязанностью процесса является обработка EINTR и перезапуск системных вызовов в случае необходимости. Хотя это обеспечивает всю функциональность, которая требуется людям, намного сложнее написать код, который обрабатывает сигналы. Всякий раз когда read() вызывается на медленном файловом дескрипторе, код должен проверять его возврат на равенство EINTR, и перезапускать вызов, либо он не будет делать то, что ожидается.

Чтобы "упростить" ситуацию, 4.2BSD автоматически перезапускает такие системные вызовы (особенно read() и write()). Поэтому для большинства операций программы более не должны беспокоиться об EINTR, поскольку выполнение системных вызовов продолжится после того, как процесс обработает сигнал. В последних версиях Unix изменен перечень системных вызовов, которые автоматически перезапускаются, a 4.3BSD позволяет вам выбрать, какие системные вызовы перезапускать. Стандарт обработки сигналов POSIX не указывает, какое поведение должно применяться, но все популярные системы согласны в том, как обрабатывать этот случай. По умолчанию системные вызовы не перезапускаются, но для каждого сигнала процесс может установить флаг, который указывает, что система должна перезапускать системные вызовы, прерванные этим сигналом.

 

12.2.1. Посылка сигналов

Посылка сигналов от одного процесса другому обычно осуществляется с помощью системного вызова kill(). Этот системный вызов подробно обсуждался в главе 10. Вариантом kill() является tkill(), который не предназначен для прямого использования в программах.

int tkill(pid_t pid, int signum);

Существуют два отличия между kill() и tkill(). Первое: pid должен быть положительным числом; tkill() не может использоваться для отправки сигналов группам процессов, как это может kill(). Другое отличие позволяет обработчикам сигналов определять, применялся ли вызов kill() или tkill() для генерации сигнала: подробности см. далее в главе.

Функция raise(), которая представляет собой способ генерации сигналов, указанный ANSI/ISO, использует системный вызов tkill() для генерации сигналов в системах Linux.

int raise(int signum);

Функция raise() посылает текущему процессу сигнал, указанный в signum.

 

12.2.2. Использование

sigset_t

Большинство функций сигналов POSIX принимают набор сигналов в качестве одного из своих параметров (или части одного из параметров). Тип данных sigset_t служит для представления набора сигналов и определен в . POSIX определяет пять функций для манипулирования наборами сигналов.

#include

int sigemptyset(sigset_t *set);

int sigfillset(sigset_t *set);

int sigaddset(sigset_t *set, int signum);

int sigdelset(sigset_t *set, int signum);

int sigismember(const sigset_t *set, int signum);

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

 

12.2.3. Перехват сигналов

Вместо использования функции signal() (чья семантика в процессе эволюции стала неправильной) POSIX-программы регистрируют обработчики сигналов с помощью sigaction().

#include

int sigaction(int signum, struct sigaction *act, struct sigaction *oact);

Этот системный вызов устанавливает обработчик сигнала signum, как определено с помощью act. Если oact не равен NULL, он принимает расположение обработчика перед вызовом sigaction(). Если act равен NULL, текущая установка обработчика остается неизменной, позволяя программе получить текущее расположение, не изменяя его. sigaction() возвращает 0 в случае успеха и ненулевое значение в случае ошибки. Ошибки случаются только если один или несколько параметров, переданных sigaction(), не верны.

Обработка сигнала ядром полностью описывается структурой struct sigaction.

#include

struct sigaction {

 __sighandler_t sa_handler;

 sigset_t sa_mask;

 int sa_flags;

};

sa_handler — это указатель на функцию со следующим прототипом:

void handler(int signum);

Здесь signum устанавливается равным номеру сигнала, который является причиной вызова функции, sa_handler может указывать на функцию этого типа либо быть равным SIG_IGN или SIG_DFL.

Программа также специфицирует набор сигналов, которые должны блокироваться во время функционирования обработчика сигнала. Если обработчик предназначен для обработки нескольких различных сигналов (что легко сделать благодаря параметру signum), это средство существенно для предотвращения возникновения условия состязаний. sa_mask — это набор сигналов, включающий все сигналы, которые должны блокироваться при вызове обработчика. Однако доставленный сигнал блокируется независимо от того, что содержит sa_mask — если вы не хотите, чтобы он блокировался, укажите это флагом sa_flags — членом структуры struct sigaction.

Член sa_flags позволяет процессу модифицировать различные поведения сигнала. Он содержит один или более флагов, объединенных битовой операцией "ИЛИ".

 

12.2.4. Манипулирование маской сигналов процесса

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

Пример немного прояснит эту проблему. Ниже показан простой обработчик SIGHUP, изменяющий значение строки, на которую указывает глобальная переменная someString.

void handleHup(int signum) {

 free(someString);

 someString = strdup("другая строка");

}

В реальных программах новое значение someString вероятно, будет читаться из внешнего источника (такого как FIFO), но некоторые концепции актуальны и так. Теперь предположим, что основная часть программы копирует строку (этот код аналогичен реализации strcpy(), хотя и не очень оптимизирован), когда поступает сигнал SIGHUP.

src = someString;

while(*src)

*dest++ = *src++;

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

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

Набор сигналов, которые процесс блокирует, часто называют маской сигнала этого процесса. Маска сигналов процесса задается типом sigset_t и содержит сигналы, заблокированные в данный момент. Функция sigprocmask() позволяет процессу управлять его текущей маской сигналов.

#include

int sigprocmask(int what, sigset_t *set, sigset_t *oldest);

Первый параметр, what, описывает, как должна выполняться манипуляция. Если set равно NULL, то what игнорируется.

Во всех трех случаях параметр oldset типа sigset_t указывает на исходную маску сигналов, если только он не равен NULL — в этом случае oldset игнорируется. Следующий вызов ищет текущую маску сигналов для запущенных процессов.

sigprocmask(SIG_BLOCK, NULL, ¤tSet);

Системный вызов sigprocmask позволяет исправить код, представленный выше, который мог вызвать состояние состязаний. Все, что потребуется сделать — это блокировать SIGHUP перед копированием строки и разблокировать после копирования. Следующее усовершенствование делает код более безопасным.

sigset_t hup;

sigemptyset(&hup);

sigaddset(&hup, SIGHUP);

sigprocmask(SIG_BLOCK, &hyp, NULL);

src = someString;

while(*src)

 *dest++ = *src++;

sigprocmask(SIG_UNBLOCK, &hup, NULL);

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

 

12.2.5. Нахождение набора ожидающих сигналов

Очень легко найти сигналы, находящиеся в состоянии ожидания (сигналы, которые должны быть доставлены, но в данный момент заблокированы).

#include

int sigpending(sigset_t *set);

Эта функция записывает по адресу, указанному set, набор сигналов, которые в данный момент находятся в состоянии ожидания.

 

12.2.6. Ожидание сигналов

Когда программа построена преимущественно вокруг сигналов, часто необходимо, чтобы она ожидала появления какого-то сигнала, прежде чем продолжать работу. Системный вызов pause() предоставляет простую возможность для этого.

#include

int pause(void);

Функция pause() не возвращает управления до тех пор, пока сигнал не будет доставлен процессу. Если зарегистрирован обработчик для этого сигнала, то он запускается до того, как pause() вернет управление, pause() всегда возвращает -1 и устанавливает errno равным EINTR.

Системный вызов sigsuspend() предлагает альтернативный метод ожидания вызова сигнала.

#include

int sigsuspend(const sigset_t *mask);

Как и pause(), sigsuspend() временно приостанавливает процесс до тех пор, пока не будет получен сигнал (и обработан связанным с ним обработчиком, если таковой предусмотрен), возвращая -1 и устанавливая errno в EINTR.

В отличие от pause(), sigsuspend() временно устанавливает маску сигналов процесса в значение, находящееся по адресу, указанному в mask, на период ожидания появления сигнала. Как только сигнал поступает, маска сигналов восстанавливается в то значение, которое она имела до вызова sigsuspend(). Это позволяет процессу ожидать появления определенного сигнала за счет блокирования всех остальных сигналов.

 

Linux предоставляет в распоряжение процессов сравнительно немного сигналов, и все они собраны в табл. 12.1.

Таблица 12.1. Сигналы

Предусмотрены четыре действия по умолчанию, которые ядро может предпринять при поступлении сигнала: игнорировать его, приостановить процесс (он остается жив и может быть перезапущен позднее), прервать процесс либо прервать процесс и сбросить дамп памяти ядра. Ниже приведено более подробное описание каждого из перечисленных в табл. 12.1 сигналов.

 

12.3.1. Описание сигналов

Иногда приложения нуждаются в описании сигнала для отображения пользователю или помещения в журнал. Существуют три способа сделать это (см. главу 9). К сожалению, ни один из них не стандартизован.

Самый старый метод предусматривает применение sys_siglist — массива строк, описывающих каждый сигнал, проиндексированного номерами самих сигналов. Он включает описания всех сигналов за исключением сигналов реального времени. Применение sys_siglist более переносимо, чем прочие методы, описанные ниже. В системах BSD предусмотрена функция psignal(), которая является сокращенным способом отображения сообщений. Вот как выглядит версия psignal().

#include

#include

void psignal(int signum, const char *msg) {

 printf("%s: %s\n", msg, sys_siglist[signum]);

}

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

Библиотека GNU С, используемая Linux, предлагает еще один метод — strsignal(). Эта функция не входит ни в какой стандарт, поэтому для доступа к файлу прототипа нужно определить _GNU_SOURCE.

#define _GNU_SOURCE

#include

char *strsignal(int signum);

Подобно sys_siglist, strsignal() также представляет описание сигнала по номеру signum. Он использует sys_siglist для большинства сигналов и конструирует описания для сигналов реального времени. Например, SIGRTMIN + 5 будет описан как "Real-time signal 5". Пример использования strsignal() можно найти в строках 639–648 и 717 файла ladsh4.с, приведенного в приложении Б.

 

Учитывая некоторые ограничения модели сигналов POSIX, например, недостающую возможность присоединения к сигналам никаких данных и вероятность того, что множество сигналов сольются в одной доставке, было разработано расширение POSIX Real Time Signals (сигналы реального времени POSIX). Системы, которые поддерживают сигналы реального времени, включая Linux, также поддерживают описанный ранее традиционный механизм сигналов POSIX. Для обеспечения наивысшего уровня переносимости между системами, мы советуем использовать стандартные интерфейсы POSIX, если только не возникает необходимости в некоторых дополнительных средствах, предоставляемых расширением реального времени.

 

12.6.1. Очередность и порядок сигналов

Два из ограничений стандартной модели сигналов POSIX заключаются в том, что когда сигнал перебивает сигнал, это не приводит к множественной доставке этих сигналов, и отсутствуют гарантии упорядоченной доставки множества разнородных сигналов (если вы пошлете SIGTERM, а следом SIGKILL, то нет способа узнать, какой из них придет первым). Расширение POSIX Real Time Signals добавляет новый набор сигналов, которые не подпадают под упомянутые ограничения.

Существует множество доступных сигналов реального времени, и они не используются ядром ни для каких предопределенных целей. Все сигналы между SIGRTMIN и SIGRTMAX являются сигналами реального времени, хотя точные номера их в POSIX не специфицированы (на момент написания этой книги Linux предоставляет 32 таких сигнала, но в будущем их количество может увеличиться).

Сигналы реального времени всегда ставятся в очередь; каждый такой сигнал, посланный приложению, доставляется ему (если только приложение не прервано перед тем, как такой сигнал будет доставлен). Упорядочение сигналов реального времени также хорошо определено. Сигналы с меньшими номерами всегда доставляются перед сигналами с большими номерами, и когда множество сигналов с одинаковым номером поставлены в очередь, то они доставляются в порядке постановки. Порядок доставки сигналов, не относящихся к расширению реального времени, не определен, как и порядок доставки смеси сигналов реального времени и не относящихся к ним.

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

 1: /* queued.с */

 2:

 3: /* получить определение strsignal() из string.h */

 4: #define _GNU_SOURCE1

 5:

 6: #include

 7: #include

 8: #include

 9: #include

10: #include

11:

12: /* Глобальные переменные для построения списка сигналов */

13: int nextSig = 0;

14: int sigOrder[10];

15:

16: /* Перехватить сигнал и записать, что он был обработан */

17: void handler(int signo) {

18:  sigOrder[nextSig++] = signo;

19: }

20:

21: int main() {

22:  sigset_t mask;

23:  sigset_t oldMask;

24:  struct sigaction act;

25:  int i;

26:

27:  /* Обрабатываемые в программе сигналы */

28:  sigemptyset(&mask);

29:  sigaddset(&mask, SIGRTMIN);

30:  sigaddset(&mask, SIGRTMIN+1);

31:  sigaddset(&mask, SIGUSR1);

32:

33:  /* Отправить сигнал handler() и сохранять их блокированными,

34:     чтобы handler() был сконфигурирован во избежание

35:     состязаний при манипулировании глобальными переменными */

36:  act.sa_handler = handler;

37:  act.sa_mask = mask;

38:  act.sa_flags = 0;

39:

40:  sigaction(SIGRTMIN, &act, NULL);

41:  sigaction(SIGRTMIN+1, &act, NULL);

42:  sigaction(SIGUSR1, &act, NULL);

43:

44:  /* Блокировать сигналы, с которыми мы работаем, чтобы

45:     была видна очередность и порядок */

46:  sigprocmask(SIG_BLOCK, &mask, &oldMask);

47:

48:  /* Генерировать сигналы */

49:  raise(SIGRTMIN+1);

50:  raise(SIGRTMIN);

51:  raise(SIGRTMIN);

52:  raise(SIGRTMIN+1);

53:  raise(SIGRTMIN);

54:  raise(SIGUSR1);

55:  raise(SIGUSR1);

56:

57:  /* Разрешить доставку этих сигналов. Все они будут доставлены

58:     прямо перед возвратом этого вызова (для Linux; это

59:     НЕПЕРЕНОСИМОЕ поведение). */

60:  sigprocmask(SIG_SETMASK, &oldMask, NULL);

61:

62:  /* Отобразить упорядоченный список перехваченных сигналов */

63:  printf("Принятые сигналы:\n");

64:  for (i = 0; i < nextSig; i++)

65:   if (sigOrder[i] < SIGRTMIN)

66:    printf("\t%s\n", strsignal(sigOrder[i]));

67:   else

68:    printf("\tSIGRTMIN + %d\n", sigOrder[i] - SIGRTMIN);

69:

70:  return 0;

71: }

Эта программа посылает себе некоторое количество сигналов и выводит на дисплей порядок их получения. Когда сигналы отправляются, она блокирует их, чтобы предотвратить немедленную доставку. Также она блокирует сигналы всякий раз, когда вызывается обработчик, устанавливая значение члена sa_mask структуры struct sigaction при настройке обработчика для каждого сигнала. Это предотвращает возможное состояние состязаний при обращении к глобальным переменным nextSig и sigOrder изнутри обработчика.

Запуск этой программы выдаст показанные ниже результаты.

Принятые сигналы:

        User defined signal1

        SIGRTMIN + 0

        SIGRTMIN + 0

        SIGRTMIN + 0

        SIGRTMIN + 1

        SIGRTMIN + 1

Это показывает, что все сигналы реального времени были доставлены, в то же время, был доставлен только один экземпляр сигнала SIGUSR1. Вы также видите изменение порядка сигналов реального времени — все сигналы SIGRTMIN были доставлены перед SIGRTMIN + 1.

 

Сигналы, которые мы обсуждали до сих пор, не несли в себе никаких данных; появление сигнала — это единственная информация, которую получает приложение. В некоторых случаях было бы неплохо знать, что послужило причиной отправки сигнала (как, например, неправильная адресация памяти, генерирующая SIGSEGV), или же иметь возможность включить данные в сигналы, генерируемые приложением. Расширение реального времени Real Time Signals позволяет решить обе эти задачи.

 

12.7.1. Получение контекста сигнала

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

void handler(int signum, siginfo_t *siginfo, void *context);

Приложение должно указать ядру на необходимость передачи полной информации о контексте, устанавливая флаг SA_SIGINFO члена sa_mask структуры struct sigaction, применяемой для регистрации обработчика сигнала. Член sa_handler также не используется, потому что он является указателем на функцию с другим прототипом. Вместо этого новый член, sa_sigaction, указывает на обработчик сигнала с правильным прототипом. Чтобы снизить потребление памяти, sa_handler и sa_sigaction разрешено использовать один и тот же участок памяти, поэтому только один из двух должен применяться в одно и то же время. Чтобы сделать это прозрачным, библиотека С определяет struct sigaction следующим образом.

#include

struct sigaction {

 union {

  __sighandler_t sa_handler;

  __sigaction_t sa_sigaction;

 } __sigaction_handler;

 sigset_t sa_mask;

 unsigned long sa_flags;

};

#define sa_handler __sigaction_handler.sa_handler

#define sa_sigaction __sigaction_handler.sa_sigaction

Использование представленной комбинации объединений и макросов позволяет этим двум членам разделять одну и ту же память без необходимости усложнения с точки зрения приложений.

Структура siginfo_t содержит информацию о том, где и почему был сгенерирован сигнал. Всем сигналам доступны два члена: sa_signo и si_code. Какие другие члены доступны — зависит от конкретного сигнала, и эти члены разделяют память подобно тому, как это делают члены sa_handler и sa_sigaction структуры struct sigaction. Член sa_signo содержит номер доставленного сигнала и всегда равен значению первого параметра, переданного обработчику сигнала, в то время как si_code указывает, почему сигнал был сгенерирован, и изменяется в зависимости от номера сигнала. Для большинства сигналов он может принимать перечисленные ниже значения.

SI_USER

Приложение пространства пользователя вызвало kill() для отправки сигнала. Примечание. Функция sigsend(), включенная в Linux для совместимости с некоторыми системами Unix, также выдает SI_USER.

SI_QUEUE

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

SI_TKILL

Приложение пространства пользователя вызвало tkill(). В то время как ядро Linux использует SI_TKILL, его значение не специфицировано в текущей версии библиотеки С.

Если вам нужно проверить SI_TKILL, используйте следующий сегмент кода для определения этого значения:

#ifndef SI_TKILL

#define SI_TKILL -6

#endif

SI_TKILL не специфицирован ни в каком стандарте (хотя допускается ими), поэтому его следует применять осторожно в переносимых программах.

SI_KERNEL

Сигнал сгенерирован ядром.

Когда SIGILL, SIGFPE, SIGSEGV, SIGBUS и SIGCHLD посылаются ядром, то si_code вместо si_kernel принимает значения, перечисленные в табл. 12.3.

Таблица 12.3. Значения si_code для специальных сигналов

Чтобы помочь прояснить разные значения, которые может принимать si_code, рассмотрим пример, в котором SIGCHLD генерируется четырьмя разными способами: kill(), sigqueue(), raise() (использует системный вызов tkill()) и созданием дочернего процесса, который немедленно прерывается.

 1: /* sicode.с */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7:

 8: #ifndef SI_TKILL

 9: #define SI_TKILL -6

10: #endif

11:

12: void handler(int signo, siginfo_t *info, void *f ) {

13:  static int count = 0;

14:

15:  printf("перехвачен сигнал, отправленный ");

16:  switch(info->si_code) {

17:  case SI_USER:

18:   printf("kill()\n"); break;

19:  case SI_QUEUE:

20:   printf("sigqueue()\n"); break;

21:  case SI_TKILL:

22:   printf("tkill() или raise()\n"); break;

23:  case CLD_EXITED:

24:   printf ("ядро сообщает, что дочерний процесс завершен\n"); exit(0);

25:  }

26:

27:  if (++count == 4) exit(1);

28: }

29:

30: int main() {

31:  struct sigaction act;

32:  union sigval val;

33:  pid_t pid = getpid();

34:

35:  val.sival_int = 1234;

36:

37:  act.sa_sigaction = handler;

38:  sigemptyset(&act.sa_mask);

39:  act.sa_flags = SA_SIGINFO;

40:  sigaction(SIGCHLD, &act, NULL);

41:

42:  kill(pid, SIGCHLD);

43:  sigqueue(pid, SIGCHLD, val);

44:  raise(SIGCHLD);

45:

46:  /* Чтобы получить SIGCHLD от ядра, мы создаем дочерний процесс

47:     и немедленно завершаем его. Обработчик сигнала выйдет после

48:     получения сигнала от ядра, поэтому мы просто засыпаем

49:     на время и позволяем программе прерваться подобным образом. */

50:

51:  if (!fork()) exit(0);

52:  sleep(60);

53:

54:  return 0;

55: }

Если si_code равно SI_USER, SI_QUEUE или SI_TKILL, то доступны два дополнительных члена siginfo_t: si_pid и si_uid, которые представляют идентификатор процесса, пославшего сигнал и действительный идентификатор пользователя этого процесса.

Когда ядром посылается SIGCHLD, доступны члены si_pid, si_status, si_utime и si_stime. Первый из них, si_pid, задает идентификатор процесса, состояние которого изменилось. Информация о новом состоянии доступна как в si_code (как показано в табл. 12.3) и в si_status, что идентично целому значению состояния, возвращаемому семейством функций wait().

Последние два члена, si_utime и si_stime, определяют период времени, которое потрачено дочерним приложением на работу в пользовательском режиме и в режиме ядра, соответственно (это подобно тому, что возвращают вызовы wait3() и wait4() в структуре struct rusage). Это время измеряется в тиках часов, заданных целым числом. Количество тиков в секунду задает макрос _SC_CLK_TCK, определенный в .

SIGSEGV, SIGBUS, SIGILL и SIGFPE — все они представляют si_addr, специфицирующий адрес, который вызвал сбой, описанный si code.

Ниже приведен простой пример проверки контекста сигнала. Он устанавливает обработчик сигнала для SIGSEGV, который печатает контекст сигнала и прерывает процесс. Нарушение сегментации генерируется попыткой обращения к NULL.

 1: /* catch-segv.c */

 2:

 3: #include

 4: #include

 5: #include

 6:

 7: void handler(int signo, siginfo_t *info, void *f) {

 8:  printf("перехват");

 9:  if (info->si_signo == SIGSEGV)

10:   printf("segv accessing %p", info->si_addr);

11:  if (info->si_code == SEGV_MAPERR)

12:   printf("SEGV_MAPERR");

13:  printf("\n");

14:

15:  exit(1);

16: }

17:

18: int main() {

19:  struct sigactin act;

20:

21:  act.sa_sigaction = handler;

22:  sigemptyset(&act.sa_mask);

23:  act.sa_flags = SA_SIGINFO;

24:  sigaction(SIGSEGV, &act, NULL);

25:

26:  *((int *)NULL) = 1 ;

27:

28:  return 0;

29: }

 

12.7.2. Отправка данных с сигналом

Механизм siginfo_t также позволяет сигналам, которые посылают программы, присоединять к себе один элемент данных (этот элемент может быть указателем, что позволяет неявно передавать любой необходимый объем данных). Чтобы отправить данные, используется union sigval.

#include

union sigval {

 int sival_int;

 void *sival_ptr;

};

Любой из членов объединения — sival_int или sival_ptr — может быть установлен в требуемое значение, которое включается в siginfo_t, доставляемое вместе с сигналом. Чтобы сгенерировать сигнал с union sigval, должна использоваться функция sigqueue().

#include

void *sigqueue(pid_t pid, int signum, const union sigval value);

В отличие от kill(), pid должен быть корректным идентификатором процесса (отрицательные значения не допускаются), signum указывает номер посылаемого сигнала. Подобно kill(), sigqueue() допускает нулевое значение signum нулю, чтобы проверить, позволяет ли вызывающий процесс посылать целевому сигналы, в действительности не выполняя такой посылки. Последний параметр, value, представляет собой элемент данных, передаваемый вместе с сигналом.

Чтобы принять union sigval, процесс, перехватывающий сигнал, должен использовать SA_SIGINFO при регистрации обработчика сигналов с помощью sigaction(). Когда член si_code структуры siginfo_t равен SI_QUEUE, то siginfo_t представляет член si_value, который содержит значение value, переданное sigqueue.

Ниже приведен пример отправки элемента данных с сигналом. Он устанавливает в очередь три сигнала SIGRTMIN с разными элементами данных. Он демонстрирует, что сигналы доставляются в том же порядке, что были отправлены, как мы и ожидаем при работе с сигналами реального времени. Более сложный пример, использующий сигналы для отслеживания изменений в каталогах, можно найти в главе 14.

 1: /* sigval.с */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7: #include

 8:

 9: /* Захватить сигнал и зарегистрировать факт его обработки */

10: void handler(int signo, siginfo_t *si, void *context) {

11:  printf("%d\n", si->si_value.sival_int);

12: }

13:

14: int main() {

15:  sigset_t mask;

16:  sigset_t oldMask;

17:  struct sigaction act;

18:  int me = getpid();

19:  union sigval val;

20:

21:  /* Отправить сигналы handler() и сохранять все сигналы заблокированными,

22:     чтобы handler() был сконфигурирован для перехвата с исключением

23:     состязаний при манипулировании глобальными переменными */

24:  act.sa_sigaction = handler;

25:  act.sa_mask = mask;

26:  act.sa_flags = SA_SIGINFO;

27:

28:  sigaction(SIGRTMIN, &act, NULL);

29:

30:  /* Блокировать SIGRTMIN, чтобы можно было увидеть очередь и упорядочение*/

31:  sigemptyset(&mask);

32:  sigaddset(&mask, SIGRTMIN);

33:

34:  sigprocmask(SIG_BLOCK, &mask, &oldMask);

35:

36:  /* Сгенерировать сигналы */

37:  val.sival_int = 1;

38:  sigqueue(me, SIGRTMIN, val);

39:  val.sival_int++;

40:  sigqueue(me, SIGRTMIN, val);

41:  val.sival_int++;

42:  sigqueue(me, SIGRTMIN, val);

43:

44:  /* Разрешить доставку сигналов */

45:  sigprocmask(SIG_SETMASK, &oldMask, NULL);

46:

47:  return 0;

48: }

 

Многим клиент-серверным приложениям необходимо считывать входные данные или записывать выходные данные с помощью одновременно нескольких файловых дескрипторов. Например, современные Web-браузеры открывают одновременно несколько сетевых подключений, чтобы уменьшить время загрузки Web-страницы. Это позволяет им загружать множество изображений, имеющихся на большинстве Web-страниц, быстрее, чем с помощью последовательных подключений. Кроме канала межпроцессных взаимодействий (IPC), используемого графическими браузерами для связи с X-сервером, на котором они отображаются, браузеры работают с множеством файловых дескрипторов.

Браузеру легче всего обработать эти файлы, считывая и обрабатывая данные из них (системный вызов read() в сетевом подключении, так же, как и в канале, возвращает доступные в настоящий момент данные и блокирует их только в случае неготовности). Этот подход эффективен, пока все подключения доставляют данные достаточно регулярно.

Если одно из сетевых подключений является медленным, начинают возникать проблемы. Когда браузер снова считывает из этого файла, он перестает работать, в то время как read() блокируется в ожидании поступления данных. Не стоит и упоминать, что подобное поведение не является удобоваримым для пользователя браузера.

Для иллюстрации этих проблем рассмотрим короткую программу, считывающую из двух файлов, p1 и p2. Для ее испытания откройте три сеанса работы с X-терминалом (или воспользуйтесь тремя виртуальными консолями). Создайте каналы под именами p1 и p2 (с помощью команды mknod), затем запустите cat > p1 и cat > p2 в двух терминалах, одновременно запустив mpx-blocks в третьем. После этого набирайте любой текст в каждом окно cat и смотрите, как он появляется. Помните, что две команды cat не будут записывать данные в каналы до конца строки.

 1: /* mpx-blocks.с */

 2:

 3: #include

 4: #include

 5: #include

 6:

 7: int main(void) {

 8:  int fds[2];

 9:  char buf[4096];

10:  int i;

11:  int fd;

12:

13:  if ((fds[0] = open("p1", O_RDONLY) ) < 0) {

14:   perror("open p1");

15:   return 1;

16:  }

17:

18:  if ( (fds[1] = open("p2", O_RDONLY)) < 0) {

19:   perror("open p2");

20:   return 1;

21:  }

22:

23:  fd = 0;

24:  while (1) {

25:   /* если данные доступны, прочитать и отобразить их */

26:   i = read (fds[fd], buf, sizeof (buf) - 1);

27:   if (i < 0) {

28:    perror("read");

29:    return 1;

30:   } else if (!i) {

31:    printf("канал закрыт\n");

32:    return 0;

33:   }

34:

35:   buf[i] = '\0';

36:   printf ("чтение: %s", buf);

37:

38:   /* читать из другого файлового дескриптора */

39:   fd = (fd + 1) % 2;

40:  }

41: }

Хотя программа mpx-blocks может считывать одновременно из обоих каналов, это не является особо эффективным. Она считывает из каждого канала по очереди. После запуска программа читает из первого файла, пока в нем доступны данные, второй файл игнорируется вплоть до возврата из read() для первого файла. Как только произошел возврат, первый файл игнорируется вплоть до чтения данных из второго файла. Этот метод не поддерживает гладкое мультиплексирование данных. На рис. 13.1 показана программа mpx-blocks во время выполнения.

Рис. 13.1. Примеры запуска мультиплексной передачи

 

13.1.1. Неблокируемый ввод-вывод

Как упоминалось в главе 11, неблокируемый файл можно определить с помощью системного вызова fcntl. Если медленный файл неблокируемый, read() сразу же возвращается. Если данные недоступны, она просто возвращает 0. Неблокируемый ввод- вывод предоставляет простое решение мультиплексирования, предотвращая блокирование файловых операций.

Показанная ниже модифицированная версия mpx-blocks пользуется преимуществом неблокируемого ввода-вывода для более гладкого переключения между p1 и p2.

 1: /* mpx-nonblock.c */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7:

 8: int main(void) {

 9:  int fds[2];

10:  char buf[4096];

11:  int i;

12:  int fd;

13:

14:  /* открыть оба канала в неблокирующем режиме */

15:  if ((fds[0] = open("p1", O_RDONLY | O_NONBLOCK)) < 0) {

16:   perror("open p1");

17:   return 1;

18:  }

19:

20:  if ((fds[1] = open("p2", O_RDONLY | O_NONBLOCK)) < 0) {

21:   perror("open p2");

22:   return 1;

23:  }

24:

25:  fd = 0;

26:  while (1) {

27:   /* если данные доступны, прочитать и отобразить их */

28:   i = read(fds[fd], buf, sizeof (buf) - 1);

29:   if ((i < 0) && (errno ! = EAGAIN)) {

30:    perror("read");

31:    return 1;

32:   } else if (i > 0) {

33:    buf[i] = '\0';

34:    printf("чтение: %s", buf);

35:   }

36:

37:   /* читать из другого файлового дескриптора */

38:   fd = (fd + 1) % 2;

39:  }

40: }

Важное различие между mpx-nonblock и mpx-blocks состоит в том, что программа mpx-nonblock не закрывается, когда один из каналов, из которого она считывает, закрыт. Неблокируемый read() из канала без записывающих устройств возвращает 0 байт, из канала с таковыми, но без доступных данных read() возвращает EAGAIN.

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

 

13.1.2. Мультиплексирование с помощью

poll()

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

#include

int poll(struct pollfd * fds, int numfds, int timeout);

Последние два параметра очень просты; numfds задает количество элементов в массиве, на который указывает первый параметр, a timeout определяет, насколько долго poll() должна ожидать события. Если в качестве тайм-аута задается 0, poll() никогда не входит в состояние тайм-аута.

Первый параметр, fds, описывает, какие файловые дескрипторы следует контролировать, и для каких типов ввода-вывода. Это указатель на массив структур struct pollfd.

struct pollfd {

 int fd;        /* файловый дескриптор */

 short events;  /* ожидаемые события ввода-вывода */

 short revents; /* происшедшие события ввода-вывода */

};

Первый элемент, fd, является контролируемым файловым дескриптором, а элемент events описывает, какие типы событий подлежат мониторингу. Последний представляет собой один или несколько перечисленных флагов, объединенных с помощью логического "ИЛИ".

Элемент revents структуры struct pollfd заполняется системным вызовом poll() и отражает состояние файлового дескриптора fd. Это похоже на элемент events, но вместо определения интересующих приложение событий ввода-вывода он определяет доступные такие типы. Например, если приложение контролирует канал как для чтения, так и для записи (events установлено в POLLIN | POLLOUT), после успешного вызова poll() в revents устанавливается бит POLLIN, если канал готов для чтения, и бит POLLOUT, если в канале имеется пространство для записи дополнительных данных. Если верно и то, и другое, устанавливаются оба бита.

Существует несколько битов, которые ядро может установить в revents, но которые невозможно установить в events.

Возвращаемое значение poll() равно нулю в случае тайм-аута вызова, -1 в случае ошибки (например, fds — неверный указатель; ошибки в самих файлах вызывают установку POLLERR), или же положительное число, описывающее количество файлов с ненулевыми элементами revents.

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

 1: /* mpx-poll.с */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7:

 8: int main(void) {

 9:  struct pollfdfds[2];

10:  char buf [4096];

11:  int i, rc;

12:

13:  /* открыть оба канала */

14:  if ( (fds[0].fd = open("p1", O_RDONLY | O_NONBLOCK)) < 0) {

15:   perror("open p1");

16:   return 1;

17:  }

18:

19:  if ((fds[1].fd = open("p2", O_RDONLY | O_NONBLOCK)) < 0) {

20:   perror("open p2");

21:   return 1;

22:  }

23:

24:  /* начать чтение из обоих файловых дескрипторов */

25:  fds[0].events = POLLIN;

26:  fds[1].events = POLLIN;

27:

28:  /* пока наблюдаем за одним из fds[0] или fds[1] */

29:  while (fds[0].events || fds[1].events ) {

30:   if (poll(fds, 2, 0) < 0) {

31:    perror("poll");

32:    return 1;

33:   }

34:

35:   /* проверить, какой из файловых дескрипторов

36:      готов для чтения из него */

37:   for (i = 0; i < 2; i++) {

38:    if (fds[i].revents) {

39:     /* fds[i] готов для чтения, двигаться дальше... */

40:     rc = read(fds[i].fd, buf, sizeof(buf) - 1);

41:     if (rc < 0) {

42:      perror("read");

43:      return 1;

44:     } else if (!rc) {

45:      /* этот канал закрыт, не пытаться

46:         читать из него снова */

47:      fds[i].events = 0;

48:     } else {

49:      buf[rc] = '\0';

50:      printf("чтение : %s", buf);

51:     }

52:    }

53:   }

54:  }

55:

56:  return 0;

57: }

 

13.1.3. Мультиплексирование с помощью

select()

Системный вызов poll() был изначально представлен как часть Unix-дерева System V. Усилиями разработчиков BSD та же основная проблема была решена похожим способом — предоставлением системного вызова select().

#include

int select(int numfds, fd_set * readfds, fd_set * writefds,

 fd_set * exceptfds, struct timeval * timeout);

Три промежуточных параметра — readfds, writefds и exceptfds — определяют, за какими файловыми дескрипторами необходимо следить. Каждый параметр — это указатель на fd_set, структуру данных, позволяющую процессу определить произвольное количество файловых дескрипторов. Ею манипулируют с помощью перечисленных ниже макросов.

Первый набор файловых дескрипторов select(), readfds, содержит перечень файловых дескрипторов, вызывающих возврат вызова select(), когда они готовы для чтения или (для каналов и сокетов) когда процесс на другом конце файла закрыл его. Когда любой файловый дескриптор в writefds готов к записи, select() возвращается, exceptfds содержит файловые дескрипторы для слежения за исключительными условиями. В Linux (так же, как и в Unix) это происходит только при поступлении внешних данных в сетевое подключение. В качестве любого из них можно указать NULL, если тот или иной тип события вас не интересует.

Окончательный параметр, timeout, определяет, насколько долго (в миллисекундах) вызову select() необходимо ожидать какого-либо события. Это указывает на struct timeval, которая выглядит следующим образом.

#include

struct timeval {

 int tv_sec; /* секунды */

 int tv_usec; /* микросекунды */

};

Первый элемент — tv_sec — это количество оставшихся секунд, a tv_usec — это количество оставшихся микросекунд. Если значением timeout является NULL, select() блокируется до следующего события. Если он указывает на struct timeval, содержащую 0 в обоих элементах, вызов select() не блокируется. Он обновляет наборы файловых дескрипторов, чтобы определить, какой файловый дескриптор в настоящее время готов для чтения или записи, а затем немедленно возвращается.

Первый параметр, numfds, вызывает наибольшие трудности. Он задает количество файловых дескрипторов (начиная с файлового дескриптора 0), которое может быть определено с помощью fd_sets. Еще один (и, возможно, более легкий) способ поведения numfds намного лучше максимального файлового дескриптора select().

Поскольку Linux обычно позволяет каждому процессу иметь до 1024 файловых дескрипторов, numfds избавляет ядро от необходимости просмотра всех 1024 файловых дескрипторов, которые может содержать каждая структура fd_set, что улучшает показатели производительности.

После возврата три структуры fd_set содержат файловые дескрипторы с задержкой входных данных, на которые можно произвести запись или которые находятся в исключительном состоянии. Вызов select() в Linux возвращает общее количество элементов, установленных в трех структурах fd_set, 0 в случае тайм-аута вызова либо -1 в случае ошибки. Однако многие системы Unix считают определенные файловые дескрипторы в возвращаемом значении только один раз, даже если они находятся как в readfds, так и в writefds, поэтому в целях переносимости лучше совершать проверку только тогда, когда возвращаемое значение больше 0. Если возвращаемое значение равно -1, не думайте, что структуры fd_set остаются незатронутыми. Linux обновляет их только в случае, если select() возвращает значение больше 0, однако некоторые системы Unix демонстрируют иное поведение.

Еще одним параметром, связанным с переносимостью, является timeout. Ядра Linux обновляют его, чтобы отобразить количество времени, оставшегося до тайм-аута вызова select(), но большинство других систем Unix его не обновляют. Однако другие системы не обновляют тайм-аут с целью соответствия более привычной реализации.

Для переносимости устраните зависимость от поведения и явно настройте структуру timeout перед вызовом select().

Теперь рассмотрим несколько примеров применения select(). Для начала используем select() без связи с файлами, создав вторичный вызов sleep().

#include

#include

int usecsleep(int usees) {

 struct timeval tv;

 tv.tv_sec = 0;

 tv.tv_usec = useсs;

 return select(0, NULL, NULL, NULL, &tv);

}

Этот код разрешает переносимые паузы длительностью менее секунды (это обеспечивает также библиотечная функция BSD usleep(), но select() намного более переносима). Например, usecsleep(500000) вызывает паузу минимум на полсекунды.

Вызов select() также используется для решения примера мультиплексирования каналов, с которым мы работали. Решение очень похоже на решение при использовании poll().

 1: /* mpx-select.c */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7:

 8: int main(void) {

 9:  int fds[2];

10:  char buf[4096];

11:  int i, rc, maxfd;

12:  fd_set watchset; /* fds для чтения */

13:  fd_set inset; /* обновляется select() */

14:

15:  /* открыть оба канала */

16:  if ((fds[0] = open("p1", O_RDONLY | O_NONBLOCK)) < 0) {

17:   perror("open p1");

18:   return 1;

19:  }

20:

21:  if ((fds[1] = open("p2", O_RDONLY | O_NONBLOCK)) < 0) {

22:   perror("open p2");

23:   return 1;

24:  }

25:

26:  /* начать чтение из обоих файловых дескрипторов */

27:  FD_ZERO(&watchset);

28:  FD_SET(fds[0], &watchset);

29:  FD_SET(fds[1], &watchset);

30:

31:  /* найти максимальный файловый дескриптор */

32:  maxfd = fds[0] > fds[1] ? fds[0] : fds[1];

33:

34:  /* пока наблюдаем за одним из fds[0] или fds[1] */

35:  while (FD_ISSET(fds[0], &watchset) ||

36:   FD_ISSET(fds[1], &watchset)) {

37:   /* здесь копируем watchset, потому что select() обновляет его */

38:   inset = watchset;

39:   if (select(maxfd + 1, &inset, NULL, NULL, NULL) < 0) {

40:    perror("select");

41:    return 1;

42:   }

43:

44:   /* проверить, какой из файловых дескрипторов

45:      готов для чтения из него */

46:   for (i = 0; i < 2; i++) {

47:    if (FD_ISSET(fds[i], &inset )) {

48:     /* fds[i] готов для чтения, двигаться дальше... */

49:     rc = read(fds[i], buf, sizeof (buf) - 1);

50:     if (rc < 0) {

51:      perror("read");

52:      return 1;

53:     } else if (!rc) {

54:      /* этот канал закрыт, не пытаться

55:         читать из него снова */

56:      close(fds[i]);

57:      FD_CLR(fds[i], &watchset);

58:     } else {

59:      buf[rc] = '\0';

60:      printf("чтение: %s", buf);

61:     }

62:    }

63:   }

64:  }

65:

66:  return 0;

67: }

 

13.1.4. Сравнение

poll()

и

select()

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

Более важное отличие связано с производительностью. Интерфейс poll() обладает несколькими свойствами, делающими его намного эффективнее, чем select().

1. При использовании select() ядру необходимо проверить все файловые дескрипторы между 0 и numfds - 1, чтобы убедиться, заинтересовано ли приложение в событиях ввода-вывода для этого файлового дескриптора. Для приложений с большим количеством открытых файлов это может привести к существенным затратам, поскольку ядро проверяет, какие именно файловые дескрипторы являются объектом интереса.

2. Набор файловых дескрипторов передается ядру как битовая карта для select() и как список для poll(). Сложные битовые операции, необходимые для проверки и установки структур данных fd_set, менее эффективны, чем простые проверки, требуемые для struct pollfd.

3. Поскольку ядро переписывает структуры данных, передаваемые select(), приложение вынуждено сбрасывать эти структуры каждый раз перед вызовом select(). С poll() результаты ядра ограничены элементом revents, что устраняет потребность в восстановлении структур данных после каждого вызова.

4. Использование структуры, основанной на множествах (например, fd_set) не масштабируется по мере увеличения количества доступных процессу файловых дескрипторов. Поскольку ее размер статичен, а не динамичен (обратите внимание на отсутствие соответствующего макроса, например, FD_FREE), она не может расширяться или сжиматься в соответствии с потребностями приложения (или возможностями ядра). В Linux максимальный файловый дескриптор, который можно установить в fd_set, равен 1023. Если понадобится больший файловый дескриптор, select() работать не будет.

Единственным преимуществом select() перед poll() является лучшая переносимость в старые системы. Поскольку небольшое количество таких реализаций все еще используется, следует применять select(), прежде всего, для понимания и эксплуатации существующих кодовых баз.

Следующая короткая программа, подсчитывающая количество системных вызовов в секунду, демонстрирует, насколько poll() эффективнее select().

 1: /* select-vs-poll.с */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7: #include

 8: #include

 9:

10: int gotAlarm;

11:

12: void catch(int sig) {

13:  gotAlarm = 1;

14: }

15:

16: #define HIGH_FD 1000

17:

18: int main(int argc, const char ** argv) {

19:  int devZero;

20:  int count;

21:  fd_set select Fds;

22:  struct pollfd pollFds;

23:

24:  devZero = open("/dev/zero", O_RDONLY);

25:  dup2(devZero, HIGH_FD);

26:

27:  /* с помощью signal выяснить, когда время истекло */

28:  signal(SIGALRM, catch);

29:

30:  gotAlarm =0;

31:  count = 0;

32:  alarm(1);

33:  while (!gotAlarm) {

34:   FD_ZERO(&selectFds);

35:   FD_SET(HIGH_FD, &selectFds);

36:

37:   select(HIGH_FD + 1, &selectFds, NULL, NULL, NULL);

38:   count++;

39:  }

40:

41:  printf("Вызовов select() в секунду: %d\n", count);

42:

43:  pollFds.fd = HIGH_FD;

44:  pollFds.events = POLLIN;

45:  count = 0;

46:  gotAlarm = 0;

47:  alarm(1);

48:  while (!gotAlarm) {

49:   poll(&pollFds, 0, 0);

50:   count++;

51:  }

52:

53:  printf("Вызовов poll() в секунду: %d\n", count);

54:

55:  return 0;

56: }

Здесь используется устройство /dev/zero, предоставляющее бесконечное количество нулей, что обеспечивает немедленный возврат системных вызовов. Значение HIGH_FD можно изменить, чтобы посмотреть, как деградирует select() по мере роста значений файловых дескрипторов.

В определенной системе при не очень высоком значении HIGH_FD, равном 2, программа показала, что ядро за секунду может обрабатывать в четыре раза больше вызовов poll(), чем вызовов select(). При увеличении HIGH_FD до 1000 эффективность poll() становится в 40 раз выше, чем у select().

 

13.1.5. Мультиплексирование с помощью

epoll

В версии 2.6 ядра Linux был предложен третий метод для мультиплексированного ввода-вывода по имени epoll. Будучи более сложным, чем poll() или select(), epoll ликвидирует узкие места, связанные с производительностью, которые характерны для обоих методов.

Оба системных вызова poll() и select() передают на проверку полный список файловых дескрипторов при каждом вызове. Каждый из этих дескрипторов должен быть обработан системным вызовом, даже если только один из них готов к чтению или записи. Когда проверяются десятки, сотни или тысячи файловых дескрипторов, эти системные вызовы превращаются в узкие места; ядро тратит много времени на выяснение того, какие именно файловые дескрипторы приложению необходимо проверить.

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

Преимущества в плане производительности epoll требуют более сложного, чем у poll() или select(), интерфейса системных вызовов. В то время как poll() использует массив struct pollfd для предоставления набора файловых дескрипторов, a select() с той же целью — три разных структуры fd_set, epoll перемещает эти наборы файловых дескрипторов в ядро, а не хранит их в адресном пространстве программы. На каждый из этих наборов ссылаются с помощью дескриптора epoll, являющегося файловым дескриптором, который можно применять только для системных вызовов epoll. Новые дескрипторы epoll распределяются системным вызовом epoll_create().

#include

int epoll_create (int numDescriptors);

Единственный параметр numDescriptors — это наилучшее предположение программы о том, на какое количество файловых дескрипторов будет ссылаться заново созданный дескриптор epoll. Это не жесткий предел, это просто подсказка ядру для более точной инициализации его внутренних структур. epoll_create() возвращает дескриптор epoll, а когда программа заканчивает работу с дескриптором, его следует передать close(), чтобы позволить ядру освободить память, используемую этим дескриптором.

Хотя дескриптор epoll является файловым дескриптором, его следует применять только с двумя системными вызовами.

#include

int epoll_ctl(int epfd, int op, int fd, struct epoll_event * event);

int epoll_wait(int epfd, struct epoll_event * events, int maxevents,

 int timeout);

Большинство этих параметров используют структуру struct epoll_event, которая определяется, как показано ниже.

#include

struct epoll_event {

 int events;

 union {

  void * ptr;

  int fd;

  unsigned int u32;

  unsigned long long u64;

 } data;

};

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

Второй элемент struct epoll_event, data, представляет собой объединение, содержащее целое число (для хранения файлового дескриптора), указатель, а также 32- и 64-битные целые числа. Этот элемент данных хранится в epoll и возвращается в программу всякий раз, когда происходит событие подходящего типа. Элемент data — это единственный способ, с помощью которого программе нужно выяснить, какой файловый дескриптор необходимо обслужить; интерфейс epoll не передает файловый дескриптор программе, в отличие от poll() и select() (если data не содержит файловый дескриптор). Этот метод обеспечивает дополнительную гибкость приложениям, которые отслеживают файлы как нечто, более сложное, чем простые файловые дескрипторы.

Системный вызов epoll_ctl() добавляет файловые дескрипторы к набору, на который ссылается дескриптор epfdepoll, и удаляет их из него.

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

Последним системным вызовом epoll является epoll_wait(), который блокирует до тех пор, пока один или несколько контролируемых файловых дескрипторов не будут иметь данные для чтения или же не будут готовы к записи. Первым аргументом является дескриптор epoll, а последний — тайм-аутом в секундах. Если файловые дескрипторы не готовы к обработке до истечения тайм-аута, epoll_wait() возвращает 0.

Два промежуточных параметра определяют буфер для ядра, в который можно копировать структуры struct epoll_event. Параметр events указывает на буфер, maxevents определяет, какое количество структур struct epoll_event помещается в буфер, а возвращаемое значение сообщает программе количество структур, помещенных в этот буфер (пока вызов не попадет в состояние тайм-аута либо не произойдет ошибка).

Каждый системный вызов struct epoll_event сообщает программе полное состояние контролируемого файлового дескриптора. Элемент events может иметь установленные флаги EPOLLIN, EPOLLOUT или EPOLLPRI, а также два новых флага, которые описаны ниже.

На первый взгляд это все может показаться сложным, но на самом деле это очень похоже на работу poll(). Вызов epoll_create() — это то же, что и распределение массива struct pollfd, a epoll_ctl() — это то же, что и инициализация элементов этого массива. Главный цикл, обрабатывающий файловые дескрипторы, использует epoll_wait() вместо системного вызова poll(), а close() аналогичен освобождению памяти, занимаемой массивом struct pollfd. Эти параллели помогают переписывать с применением epoll программы мультиплексирования, которые изначально были реализованы с помощью poll() или select().

Интерфейс epoll предлагает еще одну возможность, которую невозможно сравнить с poll() или select(). Поскольку дескриптор epoll в действительности является файловым дескриптором (вот почему его можно передавать close()), имеется возможность контролировать дескриптор epoll как часть еще одного дескриптора epoll либо через poll() или select(). Дескриптор epoll будет готов к чтению из любого места, а вызов epoll_wait() вернет события.

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

 1: /* mpx-epoll.c */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7: #include

 8:

 9: #include

10:

11: void addEvent(int epfd, char * filename) {

12:  int fd;

13:  struct epoll_event event;

14:

15:  if ((fd = open (filename, O_RDONLY | O_NONBLOCK)) < 0) {

16:   perror("open");

17:   exit(1);

18:  }

19:

20:  event.events = EPOLLIN;

21:  event.data.fd = fd;

22:

23:  if (epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event)) {

24:   perror("epoll_ctl(ADD)");

25:   exit(1);

26:  }

27: }

28:

29: int main(void) {

30:  char buf[4096];

31:  int i, rc;

32:  int epfd;

33:  struct epoll_event events[2];

34:  int num;

35:  int numFds;

36:

37:  epfd = epoll_create(2);

38:  if (epfd < 0) {

39:   perror("epoll_create");

40:   return 1;

41:  }

42:

43:  /* открыть оба канала и добавить их в набор epoll */

44:  addEvent(epfd, "p1");

45:  addEvent(epfd, "p2");

46:

47:  /* продолжать, пока есть один или более файловых дескрипторов

48:     для слежения */

49:  numFds = 2;

50:  while (numFds) {

51:   if ((num = epoll_wait(epfd, events,

52:    sizeof(events) / sizeof(* events),

53:    -1)) <= 0) {

54:   perror("epoll_wait");

55:   return 1;

56:  }

57:

58:  for (i = 0; i < num; i++) {

59:   /* events[i].data.fd готов для чтения */

60:

61:   rc = read(events[i].data.fd, buf, sizeof(buf) - 1);

62:   if (rc < 0) {

63:    perror("read");

64:    return 1;

65:   } else if (!rc) {

66:    /* этот канал закрыт, не пытаться

67:       читать из него снова */

68:    if (epoll_ctl(epfd, EPOLL_CTL_DEL,

69:     events[i].data.fd, &events[i])) {

70:     perror("epoll_ctl (DEL)");

71:     return 1;

72:    }

73:

74:    close(events[i].data.fd);

75:

76:    numFds--;

77:   } else {

78:    buf[rc] = '\0';

79:    printf("чтение: %s", buf);

80:

81:   }

82:  }

83:

84:  close(epfd);

85:

86:  return 0;

87: }

 

13.1.6 Сравнение

poll()

и

epoll

Методы poll() и epoll существенно отличаются; poll() хорошо стандартизован, но плохо масштабируется, в то время как epoll существует только в Linux, но очень хорошо масштабируется. Приложения, наблюдающие за небольшим количеством файловых дескрипторов и переносимости величин, должны использовать poll(), но любому приложению, которому необходимо контролировать большое количество дескрипторов, лучше применять epoll, даже если ему нужно поддерживать poll() для других платформ.

Отличия в производительности двух методов поразительны. Чтобы продемонстрировать, насколько лучше масштабируется epoll, в коде poll-vs-epoll.с измеряется количество системных вызовов poll() и epoll_wait(), которые можно создать за одну секунду для наборов файловых дескрипторов разных размеров (количество файловых дескрипторов для помещения в набор задается в командной строке). Каждый файловый дескриптор ссылается на считывающую часть канала, и они создаются с помощью dup2().

В табл. 13.1 суммируются результаты запуска poll-vs-epoll.с для установленных размеров диапазоном от одного до 100 000 файловых дескрипторов. В то время как количество системных вызовов в секунду резко падает для poll(), оно остается почти постоянным для epoll. Как поясняет эта таблица, epoll добавляет в систему намного меньше нагрузки, чем poll(), и в результате гораздо лучше масштабируется.

Таблица 13.1. Результаты сравнения poll() и epoll()

  1: /* poll-vs-epoll.с */

  2:

  3: #include

  4: #include

  5: #include

  6: #include

  7: #include

  8: #include

  9: #include

 10: #include

 11: #include

 12: #include

 13:

 14: #include

 15:

 16: int gotAlarm;

 17:

 18: void catch(int sig) {

 19:  gotAlarm = 1;

 20: }

 21:

 22: #define OFFSET 10

 23:

 24: int main(int argc, const char ** argv) {

 25:  int pipeFds[2];

 26:  int count;

 27:  int numFds;

 28:  struct pollfd * pollFds;

 29:  struct epoll_event event;

 30:  int epfd;

 31:  int i;

 32:  struct rlimit lim;

 33:  char * end;

 34:

 35:  if (!argv[1]) {

 36:   fprintf(stderr, "ожидалось число\n");

 37:   return 1;

 38:  }

 39:

 40:  numFds = strtol(argv[1], &end, 0);

 41:  if (*end) {

 42:   fprintf(stderr, "ожидалось число\n");

 43:   return 1;

 44:  }

 45:

 46:  printf("Запуск теста для %d файловых дескрипторов.\n", numFds);

 47:

 48:  lim.rlim_cur = numFds + OFFSET;

 49:  lim.rlim_max = numFds + OFFSET;

 50:  if (setrlimit(RLIMIT_NOFILE, &lim)) {

 51:   perror("setrlimit");

 52:   exit(1);

 53:  }

 54:

 55:  pipe(pipeFds);

 56:

 57:  pollFds = malloc(sizeof (*pollFds) * numFds);

 58:

 59:  epfd = epoll_create(numFds);

 60:  event.events = EPOLLIN;

 61:

 62:  for (i = OFFSET; i < OFFSET + numFds; i++) {

 63:   if (dup2(pipeFds[0], i) != i) {

 64:    printf("сбой в %d: %s\n", i, strerror(errno));

 65:    exit(1);

 66:   }

 67:

 68:   pollFds[i - OFFSET].fd = i;

 69:   pollFds[i - OFFSET].events = POLLIN;

 70:

 71:   event.data.fd = i;

 72:   epoll_ctl(epfd, EPOLL_CTL_ADD, i, &event);

 73:  }

 74:

 75:  /* с помощью signal выяснить, когда время истекло */

 76:  signal(SIGALRM, catch);

 77:

 78:  count = 0;

 79:  gotAlarm = 0;

 80:  alarm(1);

 81:  while (!gotAlarm) {

 82:   poll(pollFds, numFds, 0);

 83:   count++;

 84:  }

 85:

 86:  printf("Вызовов poll() в секунду: %d\n", count);

 87:

 88:  alarm(1);

 89:

 90:  count = 0;

 91:  gotAlarm = 0;

 92:  alarm(1);

 93:  while (!gotAlarm) {

 94:   epoll_wait(epfd, &event, 1, 0);

 95:   count++;

 96:  }

 97:

 98:  printf("Вызовов epoll() в секунду: %d\n", count);

 99:

100:  return 0;

101: }

 

Операционная система Linux позволяет процессу отображать файлы в их адресное пространство. Такое отображение создает взаимно однозначное соответствие между данными в файле и в отображаемой области памяти. Отображение в памяти обладает рядом преимуществ.

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

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

Новую память можно распределить отображением части /dev/zero, специального устройства, состоящего из нулей, или же через анонимное отображение. Средство Electric Fence, описанное в главе 7, использует этот механизм для распределения памяти.

Новую память, распределенную посредством карт памяти, можно сделать исполняемой, наполняя ее машинными командами, которые затем запускаются. Это свойство используется оперативными (just-in-time) компиляторами.

Файлы могут рассматриваться как память и читаться с использованием указателей, а не системных вызовов. Это существенно упрощает программы, избавляя от необходимости применения вызовов read(), write() и seek().

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

 

13.2.1. Выравнивание по страницам

Системная память делится на порции под названием страницы. Размер страницы изменяется в зависимости от архитектуры, и на некоторых процессорах размер страницы может изменяться ядром. Функция getpagesize() возвращает размер (в байтах) каждой страницы системы.

#include

size_t getpagesize(void);

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

Адрес памяти должен быть выровнен по страницам, если это адрес начала страницы. Иначе говоря, адрес должен быть целым, кратным размеру страницы архитектуры. В системе со страницами в 4 Кбайт адреса 0, 4 096, 16 384 и 32 768 являются выровненными по страницам (конечно, это далеко не весь список), потому что первая, вторая, пятая и девятая страницы системы начинаются с указанных адресов.

 

13.2.2. Установка отображения в памяти

Новые карты памяти создаются с помощью системного вызова mmap().

#include

caddr_tmmap(caddr_t address, size_t length , int protection, int flags,

 int fd, off_t offset);

Параметр address указывает, где именно в памяти необходимо отображать данные. Обычно address — это NULL, который означает, что для процесса не имеет значения местонахождение новой карты, и позволяет ядру выбрать любой адрес. Если адрес указан, он должен быть выровнен по страницам и в данный момент не использоваться. Если запрашиваемая карта будет конфликтовать с другой картой или не будет выровнена по страницам, mmap() может дать сбой.

Второй параметр, length, сообщает ядру, какую часть файлов следует отображать в памяти. Можно успешно отобразить больше памяти, чем количество данных в наличии у файла, но попытка доступа к нему может привести к SIGSEGV.

Процесс проверяет, какие типы доступа разрешены новой области памяти. Это должно быть одно или несколько значений из табл. 13.2, объединенных с помощью битового "ИЛИ", либо PROT_NONE, если доступ к отображаемой области запрещен. Файл может отображаться только для типов доступа, которые также были запрошены при изначальном открытии файла. Например, файл, открытый как O_RDONLY, не может быть отображен для записи с помощью PROT_WRITE.

Таблица 13.2. Флаги защиты mmap()

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

По этой причине на флаги защиты памяти, передаваемые в mmap(), следует полагаться лишь как на обеспечивающие минимальную защиту.

В flags определяются другие атрибуты отображаемой области. В табл. 13.3 описаны все флаги. Многие флаги, поддерживаемые Linux, нестандартны, но могут быть полезны при особых условиях. В табл. 13.3 приведены различия между стандартными флагами mmap() и дополнительными флагами Linux. Во всех вызовах mmap() должен быть специфицирован MAP_PRIVATE или MAP_SHARED; остальные флаги устанавливать необязательно.

Таблица 13.3. Флаги mmap()

За флагами следует файловый дескриптор, fd, для файла, который предстоит отобразить в памяти. Если применялся флаг MAP_ANONYMOUS, его значение игнорируется. Последний параметр определяет, где именно в файле должно начаться отображение. Он должен быть целым числом, кратным размеру страницы. Большинство приложений начинают отображение с начала файла, указывая в качестве offset ноль.

Системный вызов mmap() возвращает адрес, который должен храниться в указателе. Если произошла ошибка, он возвращает адрес, эквивалентный -1. Для проверки этого необходимо привести тип константы -1 к caddr_t, а не к int. Это гарантирует, что результат будет верным независимо от размеров указателей и целых чисел.

Ниже приведена программа, действующая подобно команде cat и ожидающая отдельного имени в качестве аргумента командной строки. Она открывает этот файл, отображает его в памяти и записывает целый файл на стандартное устройство вывода одним вызовом write(). Полезно сравнить этот пример с простой реализацией cat из главы 11. Код примера также иллюстрирует, что карты памяти остаются на месте после закрытия отображаемого файла.

 1: /* map-cat.с */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7: #include

 8: #include

 9: #include

10:

11: int main(int argc, const char ** argv) {

12:  int fd;

13:  struct stat sb;

14:  void * region;

15:

16:  if ( fd = open(argv[1], O_RDONLY)) < 0) {

17:   perror("open");

18:   return 1;

19:  }

20:

21:  /* Вызвать fstat для файла, чтобы узнать, сколько необходимо памяти для его отображения */

22:  if (fstat(fd, &sb)) {

23:   perror("fstat");

24:   return 1;

25:  }

26:

27:  /* можно было бы также отобразить как MAP_PRIVATE, поскольку

28:     запись в эту память не планируется */

29:  region = mmap(NULL, sb.st_size, PROT_READ, MAP_SHARED, fd, 0);

30:  if (region == ((caddr_t) -1)) {

31:   perror("mmap");

32:   return 1;

33:  }

34:

35:  close(fd);

36:

37:  if (write(1, region, sb.st_size) != sb.st_size) {

38:   perror("write");

39:   return 1;

40:  }

41:

42:  return 0;

43: }

 

13.2.3. Отмена отображения областей

После окончания отображения в памяти процесс может отменить отображение памяти с помощью munmap(). Это приводит к тому, что последующие доступы к этому адресу будут генерировать SIGSEGV (если только память не будет перераспределена) и сохраняет некоторые системные ресурсы. Отображение всех областей памяти отменяется, когда процесс заканчивает или начинает новую программу с помощью системного вызова exec().

#include

int munmap(caddr_t addr, int length);

Параметр addr — это адрес начала области памяти для отмены отображения, а length определяет, отображение какой части области памяти должно быть отменено. Обычно отображение каждой области отменяется отдельным вызовом munmap(). Linux может фрагментировать карты, если отменено отображение только части области, но такой код будет непереносимым.

 

13.2.4. Синхронизация областей памяти на диск

Если для записи в файл используется карта памяти, модифицированные страницы памяти и файл будут в течение некоторого времени отличаться. Если процессу необходимо немедленно записать страницы на диск, для этого служит msync().

#include

int msync(caddr_t addr, size_t length, int flags);

Первые два параметра, addr и length, устанавливают область для синхронизации с диском. Параметр flags устанавливает, каким образом должны синхронизироваться память и диск. Он состоит из одного или нескольких перечисленных ниже флагов, объединенных с помощью битового "ИЛИ".

 

13.2.5. Блокировка областей памяти

В Linux и многих других современных операционных системах для областей памяти можно организовать страничный обмен с диском (или отклонять, если их невозможно заменить каким-либо другим способом), когда возникает дефицит памяти. На приложения, чувствительные к ограничениям внешней синхронизации, может неблагоприятно повлиять задержка, к которой приводит подкачка страниц обратно в ОЗУ, когда это необходимо процессу. Для улучшения надежности таких приложений Linux позволяет процессу блокировать области памяти в ОЗУ, чтобы сделать эти синхронизации более предсказуемыми. В целях безопасности блокировка памяти разрешена только процессам с полномочиями привилегированного пользователя. Если блокировать области памяти сможет любой процесс, то какой-то неисправный процесс может заблокировать все ОЗУ системы и привести ее к краху. Общее количество памяти, блокируемой процессом, не может превышать предел использования RLIMIT_MEMLOCK (см. главу 10).

Для блокирования и разблокирования областей памяти применяются перечисленные ниже вызовы.

#include

int mlock(caddr_t addr, size_t length);

int mlockall(int flags);

int munlock(caddr_t addr, size_t length);

int munlockall(void);

Первый вызов, mlock(), блокирует length байт, начиная с адреса addr. За один раз должна блокироваться полная страница памяти, поэтому mlock() фактически блокирует все страницы между страницей, содержащей первый адрес, и страницей, содержащей последний адрес, включительно. После завершения mlock() все страницы, на которые распространился вызов, окажутся в ОЗУ.

Если процессу необходимо заблокировать все свое адресное пространство, применяется mlосkall(). Аргумент flags принимает значение одного или обоих описанных ниже флагов, объединенных с помощью битового "ИЛИ".

Разблокирование памяти — это почти то же, что ее блокирование. Если процесс больше не нуждается в блокировании памяти, munlockall() разблокирует все его страницы. munlock() принимает те же аргументы, что и mlock(), и разблокирует страницы, относящиеся к указанной области.

Многократное блокирование страницы эквивалентно однократному. В каждом случае отдельный вызов munlock() разблокирует страницы, подпадающие под его влияние.

 

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

Существует два типа блокирования файлов. Наиболее распространенное — рекомендательное блокирование, которое ядром принудительно не осуществляется. Это просто соглашение, которому должны следовать все процессы, имеющие доступ к файлу. Второй тип, обязательное блокирование, принудительно выполняется ядром. Когда процесс блокирует файл для записи, другие процессы, пытающиеся прочитать или записать в файл, приостанавливаются до снятия блокировки. Хотя этот метод может показаться более очевидным, обязательное блокирование вынуждает ядро совершать проверку наличия блокировок при каждом вызове read() и write(), существенно снижая производительность этих системных вызовов.

Операционная система Linux предоставляет два метода блокирования файлов: блокировочные файлы и блокирование записей.

 

13.3.1. Блокировочные файлы

Блокировочные файлы являются наиболее простым методом блокирования. Каждый нуждающийся в блокировании файл данных ассоциируется с блокировочным файлом. Когда блокировочный файл существует, файл данных считается заблокированным, и другие процессы не имеют к нему доступа. Когда блокировочный файл не существует, процесс создает его и затем получает доступ к файлу данных. До тех пор, пока процедура создания блокировочного файла атомарна (только один процесс за раз может "владеть" блокировочным файлом), этот метод гарантирует доступ к файлу со стороны только одного процесса в каждый момент времени.

Идея довольно проста. Когда процесс намеревается получить доступ к файлу, он блокирует файл следующим образом.

fd = open("somefile.lck", O_RDONLY, 0644);

if (fd >= 0) {

 close(fd);

 printf("файл уже заблокирован");

 return 1;

} else {

 /* блокировочный файл не существует, мы можем заблокировать его

    и получить доступ */

 fd = open("somefile.lck", O_CREAT | O_WRONLY, 0644");

 if (fd < 0) {

  perror("ошибка при создании блокировочного файла");

  return 1;

 }

 /* можем записать pid в файл */

 close(fd);

}

Когда процесс заканчивает обработку файла, он вызывает unlink("somefile.lck") для снятия блокировки.

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

fd = open("somefile.lck", O_WRONLY | O_CREAT | O_EXCL, 0644);

if (fd < 0 && errno == EEXIST) {

 printf("файл уже заблокирован");

 return 1;

} else if (fd < 0) {

 perror("непредвиденная ошибка при проверке блокировки");

 return 1;

}

/* можем записать pid в файл */

close(fd);

Блокировочные файлы используются для блокирования широкого ряда стандартных файлов Linux, включая последовательные порты и файл /etc/passwd. Хотя они хорошо работают со многими приложениями, им присущи и несколько серьезных недостатков.

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

• Флаг O_EXCL надежен только в локальных файловых системах. Ни одна из сетевых файловых систем, поддерживаемых Linux, не сохраняет семантику O_EXCL между несколькими машинами, блокирующими общий файл.

• Блокирование является только рекомендательным; процессы могут обновить файл, несмотря на существование блокировки.

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

 

13.3.2. Блокировка записей

С целью преодоления проблем, присущих блокировочным файлам, в System V и BSD 4.3 была добавлена блокировка записей, реализуемая с помощью системных вызовов lockf() и flock() соответственно. Стандарт POSIX определил третий механизм для блокировки записей, который использует системный вызов fcntl(). Хотя Linux поддерживает все три интерфейса, мы обсудим только интерфейс POSIX, поскольку сейчас его поддерживают почти все платформы Unix. Кроме того, функция lockf() реализована как интерфейс для fcntl(), поэтому оставшаяся часть данного обсуждения касается обоих методов.

Существуют два значительных отличия между блокировками записей и блокировочными файлами. Во-первых, блокировки записей применяются к произвольной части файла. Например, процесс А может заблокировать байты с 50-го по 200-й файла, в то время как другой процесс блокирует байты с 2500-го по 3000-й без конфликта двух блокировок. Мелкомодульное блокирование полезно, когда нескольким процессам необходимо обновить один файл. Еще одно преимущество блокирования записей заключается в том, что блокировки удерживаются в ядре, а не в файловой системе. По окончании процесса все блокировки, которые он содержит, освобождаются.

Как и блокировочные файлы, блокировки POSIX также являются рекомендательными. Linux, как и System V, предоставляет обязательный вариант блокирования записей, который можно использовать, но нарушая при этом переносимость. Блокирование файлов может работать или не работать в сетевой файловой системе (NFS). В последних версиях Linux блокирование файлов работает в NFS, если на всех машинах, участвующих в блокировке, выполняется демон блокировки NFS lockd.

При блокировке записей используются два типа блокировок: блокировка чтения и блокировка записи. Блокировки чтения также известны как разделяемые блокировки, поскольку несколько процессов могут одновременно удерживать блокировки чтения на одной и той же области. Для нескольких процессов чтение структуры данных, которая не обновляется, безопасно всегда. Когда процессу необходимо записать файл, ему понадобится блокировка записи (или эксклюзивная блокировка). Только один процесс может удерживать блокировку на определенной записи, и пока блокировка записи существует, блокировки чтения не допускаются. Это гарантирует, что процесс не повлияет на модули чтения, пока будет осуществлять запись в область.

Множество блокировок одного процесса никогда не конфликтуют друг с другом.

Если процесс имеет блокировку чтения на байтах 200—250 и пытается установить блокировку записи на байты 200–225, ему это удастся. Исходная блокировка смещается и становится блокировкой чтения на байтах 226–250, а новая блокировка записи устанавливается на байты 200–225. Это позволяет предотвратить взаимоблокировку одного процесса (хотя ситуация взаимоблокировки нескольких процессов по-прежнему возможна).

Блокирование записей POSIX осуществляется с помощью системного вызова fcntl(). В главе 11 было показано, что fcntl() выглядит следующим образом.

#include

int fcntl (int fd, int command, long arg);

Для всех операций блокировки третий параметр (arg) указывает на структуру struct flock, представленную ниже.

#include

struct flock {

 short l_type;

 short l_whence;

 off_t l_start;

 off_t l_len;

 pid_t l_pid;

};

Первый элемент, l_type, определяет тип установленной блокировки.

Следующие два элемента, l_whence и l_start, определяют начало области тем же способом, что и файловые смещения, передаваемые в lseek(). l_whence сообщает о способе интерпретации l_start и принимает одно из значений SEEK_SET, SEEK_CUR или SEEK_END; более подробно эти значения рассматривались в главе 11. Следующий элемент, l_len, сообщает размер блокировки в байтах. Если l_len равно 0, считается, что блокировка распространяется до конца файла. Последний элемент, l_pid, используется только тогда, когда запрашиваются блокировки. Он устанавливается в идентификатор процесса, владеющего запрашиваемой блокировкой.

Существуют три команды fcntl(), относящиеся к блокировке файла. Они передаются fcntl() во втором аргументе, fcntl() возвращает -1 в случае ошибки и 0 — в противном случае. Ниже перечислены допустимые значения параметра command.

Хотя F_GETLK позволяет процессу проверить, будет ли выдана блокировка, следующий код все еще не сможет получить блокировку.

fcntl(fd, F_GETLK, &lockinfo);

if (lockinfо.l_type != F_UNLCK) {

 fprintf(stderr, "конфликт блокировок\n");

 return 1;

}

lockinfо.l_type = F_RDLCK;

fcntl(fd, F_SETLK, &lockinfo);

Другой процесс мог заблокировать область между двумя вызовами fcntl(), приводя к тому, что второму вызову fcntl() не удается установить блокировку.

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

 1: /* lock.с */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7:

 8: /* выводит сообщение и ожидает нажатия

 9:    пользователем клавиши */

10: void waitforuser(char * message) {

11:  char buf[10];

12:

13:  printf("%s", message);

14:  fflush(stdout);

15:

16:  fgets(buf, 9, stdin);

17: }

18:

19: /* Получает блокировку заданного типа на файловом дескрипторе fd.

20:    Типом блокировки может быть F_UNLCK, F_RDLCK или F_WRLCK */

21: void getlock(int fd, int type) {

22:  struct flock lockinfo;

23:  char message[80];

24:

25:  /* будет блокироваться весь файл */

26:  lockinfo.l_whence = SEEK_SET;

27:  lockinfo.l_start = 0;

28:  lockinfo.l_len = 0;

29:

30:  /* продолжать попытки, пока того желает пользователь */

31:  while (1) {

32:   lockinfo.l_type = type;

33:   /* если блокировка получена, немедленно возвратиться */

34:   if (!fcntl(fd, F_SETLK, &lockinfo)) return;

35:

36:   /* найти, кто удерживает конфликтующую блокировку */

37:   fcntl(fd, F_GETLK, &lockinfo);

38:

39:   /* есть шанс, что блокировка освобождена между F_SETLK

40:      и F_GETLK; проверить, существует ли еще конфликт

41:      перед тем, как сообщать об этом */

42:   if (lockinfo.l_type != F_UNLCK) {

43:    sprintf (message, "конфликт с процессом %d... нажмите "

44:     " для повторения:", lockinfo.l_pid);

45:    waitforuser(message);

46:   }

47:  }

48: }

49:

50: int main(void) {

51:  int fd;

52:

53:  /* подготовить файл для блокировки */

54:  fd = open("testlockfile", O_RDWR | O_CREAT, 0666);

55:  if (fd < 0) {

56:   perror("open");

57:   return 1;

58:  }

59:

60:  printf("получение блокировки чтения\n");

61:  getlock(fd, F_RDLCK);

62:  printf("блокировка чтения получена\n");

63:

64:  waitforuser("\nдля продолжения нажмите :");

65:

66:  printf("освобождение блокировки\n");

67:  getlock(fd, F_UNLCK);

68:

69:  printf("получение блокировки записи\n");

70:  getlock(fd, F_WRLCK);

71:  printf("блокировка записи получена\n");

72:

73:  waitforuser("\nдля завершения нажмите :");

74:

75:  /* при закрытии файла блокировки освобождаются */

76:

77:  return 0;

78: }

С блокировками следует обращаться иначе, чем с другими файловыми атрибутами. Блокировки ассоциируются с парой (pid, inode), в отличие от многих атрибутов открытых файлов, которые связаны с файловым дескриптором или файловой структурой. Следовательно, если процесс выполняет перечисленные ниже действия, то файл уже не блокируется процессом.

1. Открытие одного файла дважды, что дает два разных файловым дескриптора.

2. Поучение блокировки чтения на одной области в обоих файловых дескрипторах.

3. Закрытие одного из файловых дескрипторов.

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

После fork() родительский процесс сохраняет свои файловые блокировки, но дочерний процесс — нет. Если бы дочерние процессы наследовали блокировки, два процесса пришли бы, в конечном счете, к блокировке записи на одной области файла.

Однако файловые блокировки наследуются в exec(). Поскольку в POSIX не определено, что происходит с блокировками после exec(), все варианты Unix сохраняют их.

 

13.3.3. Обязательные блокировки

И Linux, и System V поддерживают как обычные, так и обязательные блокировки. Обязательные блокировки устанавливаются и реализуются с помощью того же механизма fcntl(), который используется для рекомендательной блокировки записей. Блокировки считаются обязательными, если бит setgid заблокированного файла установлен, но его бит группового выполнения — нет. В противном случае применяется рекомендательное блокирование.

При активизации обязательного блокирования системные вызовы read() и write() блокируются, если они конфликтуют с уже установленными блокировками. Если процесс пытается осуществить запись в часть файла, на которой имеется блокировка чтения или записи от другого процесса, первый процесс блокируется до тех пор, пока существующая блокировка не будет снята. Подобным же образом вызовы read() блокируются на областях, включенных в обязательные блокировки записи.

Обязательное блокирование записи приводит к большей потере производительности, чем рекомендательное блокирование, поскольку каждый вызов read() и write() должен быть проверен на предмет конфликтов с блокировками. Оно также не настолько переносимо, как рекомендательное блокирование POSIX, поэтому в большинстве приложений обязательное блокирование применять не следует.

 

13.3.4. Аренда файла

И рекомендательное, и обязательное блокирование предназначены для предотвращения доступа процесса к файлу или его части, которая используется другим процессом. Когда блокировка установлена, процесс, которому необходим доступ к файлу, должен подождать завершения процесса, владеющего блокировкой. Эта структура подходит для большинства применений, но иногда программа использует файл до тех пор, пока он не понадобится другой программе, и желает получить при необходимости эксклюзивный доступ к файлу. Для этого Linux предлагает механизм аренды файлов (в других системах это называется периодическими блокировками (oplocks)).

Взятие файла в аренду позволяет процессу получать уведомления (через сигнал) о доступе к файлу со стороны другого процесса. Существуют два типа аренды: аренда чтения и аренда записи. Аренда чтения вызывает передачу сигнала при открытии файла для записи, открытии с указанием O_TRUNC или вызове truncate(). Аренда записи также посылает сигнал при открытии файла для чтения22. Аренды файлов работают только для модификаций, внесенных в файл той же системой, которая владеет арендой. Если файл локальный (не файл, доступ к которому возможен через сеть), любой подходящий доступ к файлу инициирует сигнал. Если доступ к файлу возможен через сеть, передачу сигнала вызывают только процессы на одной машине с процессо-арендатором; доступ с любой другой машины удается в случае отсутствия аренды.

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

F_SETLEASE

Аренда создается или освобождается в зависимости от значения последнего параметра, передаваемого в fcntl(); F_RDLCK создает аренду чтения, F_WRLCK — аренду записи, a F_UNLCK освобождает любую аренду, которая может существовать. Если запрашивается новая аренда, она заменяет любую существующую аренду. В случае ошибки возвращается отрицательное число; ноль или положительное число свидетельствуют об успехе операции.

F_GETLEASE

Возвращается тип аренды, существующей в настоящий момент для файла (F_RDLCK, F_WRLCK или F_UNLCK).

Когда в арендованном файле происходит одно из контролируемых событий, ядро передает сигнал удерживающему аренду процессу. По умолчанию передается SIGIO, но процесс может выбрать, какой сигнал передавать этому файлу, с помощью вызова fcntl(), в котором второй параметр установлен в F_SETSIG, а последний — в сигнал, который должен использоваться вместо SIGIO.

Использование F_SETSIG дает один значительный эффект. По умолчанию siginfo_t не передается обработчику при доставке SIGIO. Если используется F_SETSIG, даже когда сигналом, передаваемым в ядро, является SIGIO, a SA_SIGINFO был установлен при регистрации обработчика сигнала, файловый дескриптор, аренда которого инициировала событие, передается в обработчик сигналов одновременно с элементом siginfo_t по имени si_fd. Это позволяет применять отдельный сигнал к аренде множества файлов, в то время как si_fd сообщает сигналу, какому файлу необходимо уделить внимание.

Единственные два системных вызова, которые могут инициировать передачу сигнала для арендуемого файла — это open() и truncate(). Когда они вызываются процессом для арендуемого файла, они блокируются, и процессу-владельцу передается сигнал, open() или truncate() завершаются после удаления аренды с файла (или его закрытия процессом-владельцем, что вызывает удаление аренды). Если процесс, удерживающий аренду, не отменяет снятие в течение времени, указанного в файле /proc/sys/fs/lease-break-time, ядро прерывает аренду и позволяет завершиться запускающему системному вызову.

Ниже приведен пример применения владений файлами для уведомления о намерении другого процесса получить доступ к файлу. Список файлов берется командной строки, и на каждый файл помещается аренда записи. Когда другой процесс намеревается получить доступ к файлу (даже для чтения, поскольку использовалась блокировка записи), программа освобождает блокировку файла, позволяя другому процессу продолжать работу. Она также выводит сообщение о том, какой именно файл был освобожден.

 1: /* leases.с */

 2:

 3: #define GNU_SOURCE

 4:

 5: #include

 6: #include

 7: #include

 8: #include

 9: #include

10:

11: const char ** fileNames;

12: int numFiles;

13:

14: void handler (int sig, siginfo_t * siginfo, void * context) {

15:  /* Когда аренда истекает, вывести сообщение и закрыть файл.

16:     Предполагается, что первый открываемый файл получит файловый

17:     дескриптор 3, следующий - 4 и так далее. */

18:

19:  write(1, "освобождение", 10);

20:  write(1, fileNames[siginfo->si_fd - 3],

21:  strlen(fileNames[siginfo->si_fd - 3]));

22:  write(1, "\n", 1);

23:  fcntl(siginfo->si_fd, F_SETLEASE, F_UNLCK);

24:  close(siginfo->si_fd);

25:  numFiles--;

26: }

27:

28: int main(int argc, const char ** argv) {

29:  int fd;

30:  const char ** file;

31:  struct sigaction act;

32:

33:  if (argc < 2) {

34:   fprintf(stderr, "использование: %s +\n", argv[0]);

35:   return 1;

36:  }

37:

38:  /* Зарегистрировать обработчик сигналов. Указав SA_SIGINFO, предоставить

39:     обработчику возможность узнать, какой файловый дескриптор имеет

40:     истекшую аренду. */

41:  act.sa_sigaction = handler;

42:  act.sa_flags = SA_SIGINFO;

43:  sigemptyset(&act.sa_mask);

44:  sigaction(SIGRTMIN, &act, NULL);

45:

46:  /* Сохранить список имен файлов в глобальной переменной, чтобы

47:     обработчик сигналов мог иметь доступ к нему. */

48:  fileNames = argv + 1;

49:  numFiles = argc - 1;

50:

51:  /* Открыть файлы, установить используемые сигнал

52:     и создать аренду */

53:  for (file = fileNames; *file; file++) {

54:   if ((fd = open(* file, O_RDONLY)) < 0) {

55:    perror("open");

56:    return 1;

57:   }

58:

59:   /* Для правильного заполнения необходимо использовать F_SETSIG

60:      для структуры siginfo */

61:   if (fcntl(fd, F_SETSIG, SIGRTMIN) < 0) {

62:    perror("F_SETSIG");

63:    return 1;

64:   }

65:

66:   if (fcntl(fd, F_SETLEASE, F_WRLCK) < 0) {

67:    perror("F_SETLEASE");

68:    return 1;

69:   }

70:  }

71:

72:  /* Пока файлы остаются открытыми, ожидать поступления сигналов. */

73:  while (numFiles)

74:   pause();

75:

76:  return 0;

77: }

 

Несмотря на то что системные вызовы read() и write() как нельзя лучше подходят приложениям для извлечения и хранения данных в файле, все же они не всегда являются самыми быстрыми методами. Они допускают управление отдельными порциями данных; для записи же нескольких порций данных требуется несколько системных вызовов. Подобным образом, если приложению необходим доступ к данным в разных частях файла, оно должно вызывать lseek() между каждым read() или write(), удваивая количество необходимых системных вызовов. Для улучшения эффективности существуют другие системные вызовы.

 

13.4.1. Разбросанное/сборное чтение и запись

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

Linux предлагает системные вызовы readv() и writev(), реализующие разбросанное/сборное чтение и запись. В отличие от стандартных элементов своего уровня, получающих по одному указателю и размеру буфера, эти системные вызовы получают массивы записей, каждая запись которых описывает буфер. Буферы читаются или записываются в том порядке, в каком они приведены в массиве. Каждый буфер описывается с помощью структуры struct iovec.

#include

struct iovec {

 void * iov_base; /* адрес буфера */

 size_t iov_len; /* длина буфера */

};

Первый элемент, iov_base, указывает на буферное пространство. Элемент iov_len — это количество символов в буфере. Эти элементы представляют собой то же, что и второй и третий параметры, передаваемые read() и write().

Ниже показаны прототипы readv() и writev().

#include

int readv(int fd, const struct iovec * vector, size_t count);

int writev(int fd, const struct iovec * vector, size_t count);

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

Ниже приведена простая программа-пример, использующая writev() для отображения простого сообщения на стандартном устройстве вывода.

 1: /* gather.с */

 2:

 3: #include

 4:

 5: int main(void) {

 6:  struct iovec buffers[3];

 7:

 8:  buffers[0].iov_base = "hello";

 9:  buffers[0].iov_len = 5;

10:

11:  buffers[1].iov_base = " ";

12:  buffers[1].iov_len = 1;

13:

14:  buffers[2].iov_base = "world\n";

15:  buffers[2].iov_len = 6;

16:

17:  writev(1, buffers, 3);

18:

19:  return 0;

20: }

 

13.4.2. Игнорирование указателя файла

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

lseek(fd, SEEK_SET, offset1);

read(fd, buffer, bufferSize);

offset2 = someOperation(buffer);

lseek(fd, SEEK_SET, offset2);

read(fd, buffer2, bufferSize2);

offset3 = someOperation(buffer2);

lseek(fd, SEEK_SET, offset3);

read(fd, buffer3, bufferSize3);

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

#define XOPEN_SOURCE 500

#include

size_tpread(int fd, void * buf, size_t count, off_t offset);

size_t pwrite(int fd, void * buf, size_t count, off_t offset);

#endif

Это выглядит подобно прототипам read() и write() с четвертым параметром, offset. offset определяет, с какой точки файла следует читать, а в какую — записывать. Как и их "тезки", эти функции возвращают количество переданных байтов. Ниже приведена версия pread(), реализованная с помощью read() и lseek(), что облегчает понимание ее функции.

int pread (int fd, void * data, int size, int offset) {

 int oldOffset;

 int rc;

 int oldErrno;

 /* переместить указатель файла в новое расположение */

 oldOffset = lseek(fd, SEEK_SET, offset);

 if (oldOffset < 0) return -1;

 rc = read(fd, data, size);

 /* восстановить указатель файла, предварительно сохранив errno */

 oldErrno = errno;

 lseek(fd, SEEK_SET, oldOffset);

 errno = oldErrno;

 return rc;

}

 

14.1.1. Поиск текущего рабочего каталога

Функция getcwd() позволяет процессу найти имя своего текущего каталога относительно корневого каталога системы.

#include

char * getcwd(char * buf, size_t size);

Первый параметр, buf, указывает на буфер, хранящий путь к текущему каталогу. Если длина текущего пути превышает size - 1 байт (-1 позволяет пути завершаться символом '\0'), функция возвращает ошибку ЕRANGE. Если вызов удается, возвращается buf; в случае ошибки возвращается NULL. Несмотря на то что в большинстве современных оболочек поддерживается переменная окружения PWD, хранящая путь в текущий каталог, ее значение необязательно равняется значению, возвращаемому getcwd(). PWD часто содержит элементы путей, являющиеся символическими ссылками на другие каталоги, но getcwd() всегда возвращает путь, свободный от символических ссылок.

Если текущий путь неизвестен (например, во время запуска программы), буфер, содержащий текущий каталог, должен быть динамически распределен, поскольку размер текущего пути может быть произвольным. Код, должным образом читающий текущий путь, выглядит так, как показано ниже.

char * buf;

int len = 50;

buf = malloc(len);

while (!getcwd(buf, len) && errno == ERANGE) {

 len += 50;

 buf = realloc(buf, len);

}

Как и многие другие Unix-подобные системы, Linux предоставляет полезное расширение POSIX-спецификации getcwd(). Если buf является NULL, функция распределяет буфер, размер которого достаточен для содержания текущего пути, с помощью нормального механизма malloc(). Несмотря на то что вызывающий код должен позаботиться о надлежащем освобождении памяти, используемой результатом, это расширение обеспечивает лучшую очистку, нежели цикл, как показано в предыдущем примере.

Функция BSD по имени getwd() является наиболее распространенной альтернативой getcwd(), но ее определенные дефекты привели к разработке getcwd().

#include

char * getwd(char * buf);

Как и getcwd(), getwd() заполняет buf текущим путем, хотя функция не имеет представления о размере buf. getwd() никогда не записывает в буфер больше, чем PATH_MAX (определенная в ), что позволяет программам избегать переполнения буферов, но не предоставляет программе механизма поиска правильного пути, если он превышает PATH_MAX байт. Эта функция поддерживается Linux только для унаследованных приложений и не может использоваться новыми приложениями. Вместо этого применяйте правильную и более переносимую функцию getcwd().

Если для пользователей необходимо отображать текущий путь каталога, хорошим решением будет проверка переменной окружения PWD. Если она установлена, она содержит путь, который применяется пользователем и который может содержать символические ссылки на некоторые элементы пути. Этот путь обычно и должен отображаться приложением по желанию пользователя. Для облегчения задачи библиотека С в Linux предоставляет функцию get_current_dir_name(), реализуемую следующим образом.

char * get_current_dir_name() {

char * env = getenv("PWD");

if (env)

 return strdup(env);

else

 return getcwd(NULL, 0);

}

 

14.1.2. Специальные файлы

.

и

..

Каждый каталог, включая корневой, содержит также два специальных файла под именами . и .., полезные при определенных условиях. Первый, . — то же самое, что и текущий каталог. Это означает, что имена somefile и ./somefile эквивалентны.

Еще одно специальное имя файла, .., является родительским каталогом текущего каталога. В случае корневого каталога .. относится к самому корневому каталогу (поскольку у корневого каталога нет родительского каталога).

И ., и .. можно применять везде, где можно использовать имя каталога. Нормально то, что отношение символических ссылок к путям вроде ../include/mylib и именам файлов наподобие /./foo/.././bar/./fubar/../../usr/bin/less является законным (хотя эти названия довольно запутаны).

 

14.1.3. Смена текущего каталога

Предусмотрено два системных вызова, меняющих текущий каталог процесса: chdir() и fchdir().

#include

int chdir(const char * pathname);

int fchdir(int fd);

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

 

14.3.1. Создание новых каталогов

Создание новых каталогов выполняется очень просто.

#include

#include

int mkdir(const char * dirname, mode_t mode);

Путь, определенный в dirname, создается как новый каталог с полномочием mode (что модифицируется umask процесса). Если dirname определяет существующий файл, или некоторые элементы dirname не являются каталогом или символической ссылкой на него, системный вызов не удается.

 

14.3.2. Удаление каталогов

Удаление каталога — это практически то же, что и удаление файла; меняется разве что имя системного вызова.

#include

int rmdir(char * pathname);

Для успешного выполнения rmdir() каталог должен быть пустым (он не должен содержать ничего, кроме вездесущих . и ..); в противном случае возвращается ENOTEMPTY.

 

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

#include

DIR * opendir(const char * pathname);

int closedir(DIR * dir);

Системный вызов opendir() возвращает указатель на тип данных DIR, который является абстрактным (как и структура stdio по имени FILE) и которым не следует манипулировать вне библиотеки С. Поскольку каталоги можно открывать только для чтения, нет необходимости определять, в каком режиме открывается каталог, opendir() срабатывает только в случае существования каталога — этот вызов нельзя использовать для создания новых каталогов (для этого служит mkdir()). Закрытие каталога может не сработать только в случае некорректного значения аргумента dir.

После открытия каталога его элементы читаются последовательно до конца каталога.

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

#include

struct dirent * readdir (DIR * dir);

Вызывающему коду возвращается указатель на структуру struct dirent. Несмотря на то что struct dirent содержит несколько элементов, единственным переносимым элементом является d_name, содержащий имя файла элемента каталога. Остальные элементы struct dirent зависят от системы. Однако интересным является элемент d_ino, содержащий inode-номер файла.

Самой сложной частью этого процесса является определение ошибки. К сожалению, readdir() возвращает NULL, и когда происходит ошибка, и когда в каталоге больше нет элементов. Чтобы различать эти две ситуации, необходимо проверять errno. Эта задача усложняется тем, что readdir() не меняет errno, пока не произойдет ошибка. Это означает, что для корректной проверки ошибок errno необходимо установить перед вызовом readdir() в заранее известное значение (обычно 0). Ниже показана простая программа, записывающая имена файлов текущего каталога в stdout.

 1: /* dircontents.с */

 2:

 3: #include

 4: #include

 5: #include

 6:

 7: int main(void) {

 8:  DIR * dir;

 9:  struct dirent * ent;

10:

11:  /* "." - текущий каталог */

12:  if (!(dir = opendir("."))) {

13:   perror("opendir");

14:   return 1;

15:  }

16:

17:  /* установить errno в 0, чтобы можно было выяснить, когда readdir() даст сбой*/

18:  errno = 0;

19:  while ((ent = readdir(dir))) {

20:   puts (ent->d_name);

21:   /* сбросить errno, поскольку puts() может модифицировать ее */

22:   errno = 0;

23:  }

24:

25:  if (errno) {

26:   perror("readdir");

27:   return 1;

28:  }

29:

30:  closedir(dir);

31:

32:  return 0;

33: }

 

14.4.1. Прохождение по каталогу

Если требуется перечитать содержимое каталога, уже открытого opendir(), с помощью rewinddir() структура DIR сбрасывается, чтобы следующий вызов readdir() мог вернуть первый файл в каталоге.

#include

int rewinddir(DIR * dir);

 

Большинство пользователей Linux принимают как должное то, что запуск ls *.с не сообщает сведения о файле в текущем каталоге, именем которого является *.с. Вместо этого они ожидают увидеть список всех файлов в текущем каталоге, имена которых заканчиваются на .с. Это расширение имени файла от *.с до ladsh.с dircontents.с (например) обычно обрабатывается оболочкой, которая универсализирует все параметры для программ, выполняющихся под ее управлением. Программы, помогающие пользователям манипулировать файлами, тоже часто нуждаются в универсализации файловых имен. Существуют два распространенных способа универсализации имен файлов внутри программ.

 

14.5.1. Использование подпроцесса

Самый старый метод универсализации предусматривает запуск оболочки в качестве дочернего процесса и указание ей универсализировать файловые имена. Стандартная функция popen() (см. главу 10) упрощает этот метод — просто запустите команду ls *.с с помощью popen() и прочитайте результат. Этот подход может показаться несколько упрощенным, но все же он обеспечивает переносимое решение проблемы универсализации (вот почему приложения вроде Perl используют его).

Ниже приведена программа, которая универсализирует все аргументы и отображает все совпадения.

 1: /* popenglob.c */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7:

 8: int main(int argc, const char ** argv)

 9:  char buf[1024];

10:  FILE * ls;

11:  int result;

12:  int i;

13:

14:  strcpy(buf, "ls");

15:

16:  for (i = 1; i < argc; i++) {

17:   strcat(buf, argv[i]);

18:   strcat(buf, " ");

19:  }

20:

21:  ls = popen(buf, "r");

22:  if (!ls) {

23:   perror("popen");

24:   return 1;

25:  }

26:

27:  while (fgets(buf, sizeof(buf), ls))

28:   printf("%s", buf);

29:

30:  result = pclose(ls);

31:

32:  if (!WIFEXITED(result)) return 1;

33:

34:  return 0;

35: }

 

14.5.2. Внутренняя универсализация

Если необходимо универсализировать несколько файловых имен, запуск нескольких подоболочек с помощью popen() будет неэффективным. Функция glob() позволяет универсализировать имена файлов без запуска каких-либо подпроцессов, однако за счет увеличения сложности и снижения переносимости. Несмотря на то что вызов glob() описан в стандарте POSIX.2, многие варианты Unix до сих пор его не поддерживают.

#include

int glob(const char * pattern, int flags,

int (*errfunc)(const char * epath, int eerrno), glob_t* pglob);

Первый параметр, pattern, определяет шаблон, которому должны соответствовать имена файлов. В нем допускается применение операций универсализации *, ? и [], а также необязательно {, } и ~ которые трактуются так же, как в стандартных оболочках. Последний параметр указывает на структуру, которая заполняется результатами универсализации. Эта структура определена следующим образом.

#include

typedef struct {

 int gl_pathc; /* количество путей в gl_pathv */

 char **gl_pathv; /* список gl_pathc, соответствующих именам путей */

 int gl_offs; /* пространство, зарезервированное в gl_pathv для GLOB_DOOFFS*/

} glob_t;

flags — это одно или несколько перечисленных ниже значений, объединенных с помощью битового "ИЛИ".

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

Прототип этой функции показан ниже.

int globerr(const char * pathname, int globerrno);

Функции передается путевое имя, вызвавшее ошибку, и значение errno, возвращенное одним из системных вызовов opendir(), readdir() или stat(). Если функция ошибки возвращает величину больше нуля, glob() возвращается с ошибкой. В противном случае операция универсализации продолжается.

Результаты универсализации хранятся в структуре glob_t, на которую ссылается pglob. Она включает описанные ниже элементы, позволяющие абоненту найти согласованные имена файлов.

После использования возвращенного результата glob_t занимаемую им память следует освободить, передав его в globfree().

void globfree(glob_t * pglob);

Системный вызов glob() возвращает GLOB_NOSPACE в случае нехватки памяти, GLOB_ABEND, если ошибка чтения привела к неудачному выполнению функции, GLOB_NOMATCH, если соответствия не были найдены, или 0, если функция выполнилась удачно и нашла соответствия.

Для иллюстрации работы glob() ниже приведена программа globit, которая принимает множество шаблонов в качестве аргументов, универсализирует их и отображает результат. В случае ошибки отображается сообщение, описывающее ошибку, а операция универсализации продолжается.

 1: /* globit.с */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7: #include

 8:

 9: /* Это функция ошибки, которая передается в glob(). Она просто отображает

10:    сообщение об ошибке и возвращает состояние успеха, что позволяет glob()

11:    продолжить работу. */

12: int errfn(const char * pathname, int theerr) {

13:  fprintf(stderr, "ошибка при доступе к %s: %s\n", pathname,

14:  strerror(theerr));

15:

16:  /* Операция универсализации должна продолжаться, поэтому вернуть 0 */

17:  return 0;

18: }

19:

20: int main(int argc, const char ** argv) {

21:  glob_t result;

22:  int i, rc, flags;

23:

24:  if (argc < 2) {

25:   printf("необходимо передать хотя бы один аргумент\n") ;

26:   return 1;

27:  }

28:

29:  /* установить flags в 0; позже он будет изменен на GLOB_APPEND */

30:  flags = 0;

31:

32:  /* совершить проход по всем аргументам командной строки */

33:  for (i = 1; i < argc; i++) {

34:   rc = glob(argv[i], flags, errfn, &result);

35:

36:   /* благодаря errfn, GLOB_ABEND не происходит */

37:   if (rc == GLOB_NOSPACE) {

38:    fprintf(stderr, "не хватает памяти для выполнения универсализации\n");

39:    return 1;

40:   }

41:

42:   flags |= GLOB_APPEND;

43:  }

44:

45:  if (!result.gl_pathc) {

46:   fprintf(stderr, "соответствий нет\n");

47:   rc = 1;

48:  } else {

49:   for (i = 0; i < result.gl_pathc; i++)

50:    puts(result.gl_pathv[i]);

51:   rc = 0;

52:  }

53:

54:  /* структура glob_t занимает память из пула malloc(),

55:     которая должна быть освобождена */

56:  globfree(&result);

57:

58:  return rc;

59: }

 

Продолжим эволюцию ladsh, добавив к ladsh3.с четыре новых возможности.

1. Встроенная команда cd для смены каталогов.

2. Встроенная команда pwd для отображения текущего каталога.

3. Универсализация файловых имен.

4. Отображение ряда новых сообщений, позволяющее воспользоваться преимуществами strsignal(). Эти изменения обсуждались в главе 12.

 

14.6.1. Добавление встроенных команд

cd

и

pwd

Добавление встроенных команд является прямым применением вызовов chdir() и getcwd(). Код соответствует runProgram() как раз там, где обрабатываются другие встроенные команды. Ниже показан раздел обработки встроенных команд в ladsh3.с.

422: if (!strcmp(newJob.progs[0].argv[0], "exit")) {

423:  /* здесь должен возвращаться реальный код завершения */

424:  exit(0);

425: } else if (!strcmp(newJob.progs[0].argv[0], "pwd")) {

426:  len = 50;

427:  buf = malloc(len);

428:  while (!getcwd(buf, len) && errno == ERANGE) {

429:   len += 50;

430:   buf = realloc(buf, len);

431:  }

432:  printf("%s\n", buf);

433:  free(buf);

434:  return 0;

435: } else if (!strcmp(newJob.progs[0].argv[0], "cd")) {

436:  if (!new Job.progs[0].argv[1] == 1)

437:   newdir = getenv("HOME");

438:  else

439:   newdir = newJob.progs[0].argv[1];

440:  if (chdir(newdir))

441:   printf("сбой при смене текущего каталога: %s\n",

442:  strerror(errno));

443:  return 0;

444: } else if (!strcmp(newJob.progs[0].argv[0], "jobs")) {

445:  for (job = jobList->head; job; job = job->next)

446:   printf(JOB_STATUS_FORMAT, job->jobId, "Выполняется",

447:    job -> text);

448:  return 0;

449: }

 

14.6.2. Добавление универсализации файловых имен

Универсализацию файловых имен, при которой оболочка разворачивает символы *, [] и ? в соответствующие файловые имена, в определенной мере сложно реализовать из-за разнообразных методов применения кавычек. Первая модификация заключается в построении каждого аргумента в виде строки, подходящей для передачи в glob(). Если символ универсализации помещен в кавычки, принятые в оболочке (например, двойные кавычки), тогда символу универсализации предшествует \ с целью предотвращения его разворачивания в glob(). Этот процесс реализуется легко, хотя с первого взгляда может показаться сложным.

Две части синтаксического разбора команд в parseCommand() необходимо слегка изменить. Последовательности " и ' обрабатываются ближе к началу цикла, что обеспечивает разделение командной строки на аргументы. Если во время синтаксического разбора мы находимся в середине строки в кавычках и сталкиваемся с символом универсализации, мы заключаем его в кавычки с предваряющим символом \, что выглядит следующим образом.

189: } else if (quote) {

190:  if (*src == '\\') {

191:   src++;

192:   if (!*src) {

193:    fprintf(stderr,

194:     "после \\ ожидался символ\n");

195:    freeJob(job);

196:    return 1;

197:   }

198:

199:   /* в оболочке "\'" должен дать \' */

200:   if (* src ! = quote) *buf++ = '\\';

201:  } else if (*src = '*' | | *src == '?' || *src == '[' ||

202:   *src == ']')

203:   *buf++ = '\\';

204:  *buf++ = *src;

205: } else if (isspace(*src)) {

В код были добавлены только средний else if и оператор присваивания в его теле. Похожий код потребуется предусмотреть для обработки символов \, встречающихся вне строк в кавычках. Это реализовано в конце главного цикла parseCommand(). Ниже приведен измененный код.

329: case '\\':

330:  src++;

331:  if (!*src) {

332:   freeJob(job);

333:   fprintf(stderr, "после \\ ожидался символ\n");

334:   return 1;

335:  }

336:  if (* src == '*' || *srс == '[' | | *src == ']'

337:   || *srс == '?')

338:   *buf++ = '\\';

339:  /* сквозная обработка */

340: default:

341:  *buf++ = *src;

Для заключения знаков универсализации в кавычки здесь был добавлен тот же самый код.

Эти две кодовые последовательности обеспечивают передачу каждого аргумента в glob() без поиска неожиданных совпадений.

Теперь добавим функцию globLastArgument(), которая универсализирует самый последний аргумент для дочерней программы и замещает его любым найденным совпадением.

Для облегчения управления памяти к struct childProgram добавляется элемент globResult типа glob_t, используемый для хранения результатов всех операций универсализации. Кроме того, добавляется целочисленный элемент freeGlob, не равный нулю, если freeJob() должна освободить globResult. Ниже показано полное описание struct childProgram в ladsh3.c.

35: struct childProgram {

36:  pid; /* 0, если завершена */

37:  char ** argv; /* имя и аргументы программы */

38:  int numRedirections; /* элементы в массиве перенаправлений */

39:  struct redirection Specifier * redirections; /* перенаправления ввода-вывода */

40:  glob_t globResult; /* результат универсализации параметров */

41:  int freeGlob; /* нужно ли освобождать globResult? */

42: };

Во время первого запуска для командной строки функция globLastArgument() (когда argc для текущей дочерней оболочки равно 1) инициализирует globResult. Для остальных аргументов она пользуется преимуществом GLOB_APPEND для добавления новых совпадений к существующим. Это избавляет от необходимости распределения собственной памяти для целей универсализации, поскольку одиночный glob_t при необходимости автоматически расширяется.

Если globLastArgument() не находит совпадений, символы \ с кавычками удаляются из аргумента. В противном случае все новые совпадения копируются в список аргументов, создаваемый для дочерней программы.

Ниже приведена полная реализация globLastArgument(). Все сложные ее части относятся к управлению памятью; фактическая универсализация похожа на реализованную в программе globit.с, которая представлена ранее в главе.

 87: void globLastArgument(struct childProgram * prog, int * argcPtr,

 88:  int * argcAllocedPtr) {

 89:  int argc = *argcPtr;

 90:  int argcAlloced = *argcAllocedPtr;

 91:  int rc;

 92:  int flags;

 93:  int i;

 94:  char * src, * dst;

 95:

 96:  if (argc >1) {/* cmd->globResult уже инициализирован */

 97:   flags = GLOB_APPEND;

 98:   i = prog->globResult.gl_pathc;

 99:  } else {

100:   prog->freeGlob = 1;

101:   flags = 0;

102:   i = 0;

103:  }

104:

105:  rc = glob(prog->argv[argc - 1], flags, NULL, &prog->globResult);

106:  if (rc == GLOB_NOSPACE) {

107:   fprintf (stderr, "не хватает памяти для выполнения универсализации\n");

108:   return;

109:  } else if (rc == GLOB_NOMATCH ||

110:   (!rc && (prog->globResult.gl_path - i) == 1 &&

111:   !strcmp(prog->argv[argc - 1],

112:   prog->globResult.gl_pathv[i]))) {

113:    /* необходимо удалить кавычки в \, если они все еще присутствуют */

114:    src = dst = prog->argv[argc - 1];

115:    while (*src) {

116:     if (*src ! = '\\') *dst++ = *src;

117:     src++;

118:    }

119:    *dst = '\0';

120:   } else if (!rc) {

121:   argcAlloced += (prog->globResult.gl_pathc - i);

122:   prog->argv = realloc(prog->argv,

123:   argcAlloced * sizeof(*prog->argv));

124:   memcpy(prog->argv + (argc - 1),

125:    prog->globResult.gl_pathv + i,

126:    sizeof(*(prog->argv)) *

127:    (prog->globResult.gl_pathc - i));

128:   argc += (prog->globResult.gl_pathc - i - 1);

129:  }

130:

131:  *argcAllocedPtr = argcAlloced;

132:  *argcPtr = argc;

133: }

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

globLastArgument(prog, &argc, &argvAlloced);

Полный код ladsh3.с доступен на Web-сайте издательства, а также на сайте, посвященном книге.

 

Существуют две функции, которые облегчают приложениям просмотр всех файлов каталога, включая файлы в подкаталогах. Рекурсивный просмотр всех элементов древовидной структуры (например, файловой системы) часто называется обходом (walk) дерева и он реализуется функциями ftw() и nftw(). nftw() представляет собой усовершенствованную версию ftw.

 

14.7.1. Использование

ftw()

#include

int ftw(const char *dir, ftwFunctionPointer callback, int depth);

Функция ftw() начинает с каталога dir и вызывает указанную в callback функцию для каждого файла в этом каталоге и его подкаталогах. Функция вызывается для всех типов файлов, включая символические ссылки и каталоги. Реализация ftw() открывает каждый найденный каталог (с помощью файлового дескриптора) и для увеличения производительности не закрывает их, пока не закончит чтение всех элементов каталога. Это означает, что он использует количество файловых дескрипторов, равное количеству уровней подкаталогов. Чтобы предотвратить недостаток файловых дескрипторов в приложении, параметр depth ограничивает количество файловых дескрипторов ftw(), остающихся одновременно открытыми. Если этот предел достигается, производительность снижается, поскольку каталоги необходимо часто открывать и закрывать.

Функция, на которую указывает callback, определяется следующим образом:

int ftwCallbackFunction(const char * file, const struct stat * sb, int flag);

Эта функция вызывается один раз для каждого файла в дереве каталогов, а первый параметр, file, представляет собой имя файла, начинающееся с dir, которое передается ftw(). Например, если бы аргумент dir принимал значение ., одним из файловых имен было бы ./bashrc. Если бы вместо этого использовалось /etc, имя файла выглядело бы как /etc/hosts.

Следующий аргумент обратного вызова, sb, указывает на структуру struct stat как на результат применения stat() к файлу. Аргумент flag предоставляет информацию о файле и принимает одно из следующих значений.

Когда файл является символической ссылкой, ftw() пытается последовать за этой ссылкой и вернуть информацию о файле, на который она указывает (ftw() проходит один и тот же каталог несколько раз, если на него имеется несколько символических ссылок). Однако для поврежденной ссылки не определено, вернется FTW_SL или FTW_NS. Это хорошая причина, чтобы использовать nftw().

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

 

14.7.2. Обход дерева файлов с помощью

nft()

Новая версия ftw() — nftw() — решает неоднозначность символических ссылок, присущих ftw(), и содержит несколько дополнительных свойств. С целью правильного определения nftw() заголовочными файлами значение _XOPEN_SOURCE в приложении должно быть определено 500 или больше. Ниже показан прототип nftw().

#define _XOPEN_SOURCE 600

#include

int nftw(const char * dir, ftwFunctionPointer callback, int depth, int flags);

int nftwCallbackFunction(const char *file, const struct stat * sb,

 int flag, struct FTW * ftwInfo);

Сравнивая nftw() с ftw(), легко заметить новый параметр — flags. Это может быть один или несколько следующих флагов, объединенных с помощью логического "ИЛИ".

Аргумент обратного вызова flag может принимать два новых значения для nftw() вдобавок к значениям, уже упомянутым для ftw().

Эти дополнительные значения flag надлежащим образом определяют nftw() для символических ссылок. При использовании FTW_PHYS все символические ссылки возвращают FTW_SL. Без nftw() поврежденные ссылки выдают FTW_NS, а другие символические ссылки дают тот же результат, что и цель ссылки.

Обратный вызов для nftw() принимает еще один аргумент, ftwInfо. Это указатель на struct FTW, которая определяется следующим образом.

#define _XOPEN_SOURCE 600

#include

struct FTW {

 int base;

 int level;

};

Элемент base — это смещение имени файла в полном пути, передаваемое обратному вызову. Например, если переданный полный путь выглядит как /usr/bin/ls, base будет равно 9, a file + ftwInfo->base даст имя файла ls. level — это количество каталогов под текущим каталогом. Если ls был найден в nftw(), начинающемся с /usr, уровень будет равен 1. Если поиск начался с /usr/bin, уровень будет равен 0.

 

14.7.3. Реализация

find

Команда find выполняет в одном или нескольких деревьях каталогов поиск файлов, соответствующих определенным характеристикам. Ниже приведена простая реализация find, реализованная на основе nftw(). Она использует fnmatch() (см. главу 23) для реализации переключателя -name и иллюстрирует многие флаги, воспринимаемые nftw().

 1: /* find.с */

 2:

 3: #define _XOPEN_SOURCE 600

 4:

 5: #include

 6: #include

 7: #include

 8: #include

 9: #include

10: #include

11:

12: const char * name = NULL;

13: int minDepth = 0, maxDepth = INT_MAX;

14:

15: int find (const char * file, const struct stat * sb, int flags,

16:  struct FTW * f) {

17:  if (f->level < minDepth) return 0;

18:  if (f->level > maxDepth) return 0;

19:  if (name && fnmatch(name, file + f->base, FNM_PERIOD)) return 0;

20:

21:  if (flags == FTW_DNR) {

22:   fprintf(stderr, "find: %s: недопустимые полномочия\n", file);

23:  } else {

24:   printf("%s\n", file);

25:  }

26:

27:  return 0;

28: }

29:

30: int main(int argc, const char ** argv) {

31:  int flags = FTW_PHYS;

32:  int i;

33:  int problem = 0;

34:  int tmp;

35:  int rc;

36:  char * chptr;

37:

38:  /* поиск первого параметры командной строки (который должен

39:     находиться после списка путей */

40:  i = 1;

41:  while (i < argc && *argv[i] != '-') i++;

42:

43:  /* обработать опции командной строки */

44:  while (i < argc && !problem) {

45:   if (!strcmp(argv[i], "-name")) {

46:    i++;

47:    if (i == argc)

48:     problem = 1;

49:    else

50:     name = argv[i++];

51:   } else if (!strcmp(argv[i], "-depth")) {

52:    i++;

53:    flags |= FTW_DEPTH;

54:   } else if (!strcmp (argv[i], "-mount") ||

55:    !strcmp(argv[i], "-xdev")) {

56:    i++;

57:    flags |= FTW_MOUNT;

58:   } else if (!strcmp (argv[i], "-mindepth") ||

59:    !strcmp (argv[i], "-maxdepth")) {

60:    i++;

61:    if (i == argc)

62:     problem = 1;

63:    else {

64:     tmp = strtoul(argv[i++], &chptr, 10);

65:     if (*chptr)

66:      problem = 1;

67:     else if (!strcmp(argv[i - 2], "-mindepth"))

68:      minDepth = tmp;

69:     else

70:      maxDepth = tmp;

71:    }

72:   }

73:  }

74:

75:  if (problem) {

76:   fprintf(stderr, "использование: find <пути> [-name <строка>]"

77:    "[-mindepth <целое>] [-maxdepth <целое>]\n");

78:   fprintf(stderr, " [-xdev] [-depth]\n");

79:   return 1;

80:  }

81:

82:  if (argc == 1 || *argv[1] == '-') {

83:   argv[1] = ".";

84:   argc = 2;

85:  }

86:

87:  rc = 0;

88:  i = 1;

89:  flags = 0;

90:  while (i < argc && *argv[i] != '-')

91:   rc |= nftw (argv [i++], find, 100, flags);

92:

93:  return rc;

94: }

 

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

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

 

15.1.1. Перезапуск процессов

Каждый процесс может пребывать в трех состояниях: выполнение, останов и "зомби". Выполняющиеся процессы завершаются системным вызовом exit() или отправкой сигнала фатального завершения. Процессы перемещаются между состояниями работы и остановки исключительно посредством сигналов, сгенерированных другим процессом, ядром либо ими самими.

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

 

15.1.2. Остановка процессов

Четыре сигнала перемещают работающий процесс в состояние останова. SIGSTOP никогда не генерируется ядром. Он предназначен для остановки произвольных процессов. Его невозможно захватить или проигнорировать; он всегда останавливает целевой процесс. Остальные три сигнала, останавливающие процессы — SIGTSTP, SIGTTIN и SIGTTOU — могут генерироваться терминалом, на котором работает процесс, или другим процессом. Хотя эти сигналы ведут себя похожим образом, они генерируются при разных обстоятельствах.

SIGTSTP

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

SIGTTIN

Когда фоновый процесс пытается считывать из терминала, ему передается SIGTTIN.

SIGTTOU

Этот сигнал обычно генерируется фоновым процессом, пытающимся выполнить запись в свой терминал. Сигнал генерируется только в случае установки атрибута терминала TOSTOP, как рассматривается в главе 16.

Данный сигнал генерируется также фоновым процессом, вызывающим tcflush(), tcflow(), tcsetattr(), tcsetpgrp(), tcdrain() или tcsendbreak().

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

 

15.1.3. Обработка сигналов управления заданиями

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

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

При получении SIGTSTP процесс должен немедленно выполнить все необходимые ему действия, чтобы разрешить приостановку (например, восстановление исходного состояния терминала) и приостановиться самому. Самый простой способ приостановки процесса — передача самому себе сигнала SIGSTOP. Однако большинство оболочек отображают сообщения с типом сигнала, вызвавшего остановку процесса, и если процесс передаст себе sigstop, он будет отличаться от большинства приостановленных процессов. Во избежание этого неудобства многие приложения сбрасывают свой обработчик SIGTSTP в SIG_DFL и передают себе SIGTSTP.

Процессам, которые требуют специальный код для правильных приостановок, обычно необходимо выполнять специальные действия при перезапуске. Это легко делается предоставлением обработчика сигнала для SIGCONT, который выполняет такие действия. Если процесс приостанавливается с помощью SIGTSTP, такие специальные действия, возможно, включают установку обработчика сигнала для SIGTSTP.

Ниже приведен код простого обработчика сигналов SIGCONT и SIGTSTP. Когда пользователь приостанавливает или перезапускает процесс, последний отображает сообщение перед остановкой или продолжением.

 1: /* monitor.с */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7:

 8: void catchSignal(int sigNum, int useDefault);

 9:

10: void handler(int signum) {

11:  if (signum == SIGTSTP) {

12:   write(STDOUT_FILENO, "получен SIGTSTP\n", 12);

13:   catchSignal(SIGTSTP, 1);

14:   kill(getpid(), SIGTSTP);

15:  } else {

16:   write(STDOUT_FILENO, "получен SIGCONT\n", 12);

17:   catchSignal(SIGTSTP, 0);

18:  }

19: }

20:

21: void catchSignal(int sigNum, int useDefault) {

22:  struct sigaction sa;

23:

24:  memset(&sa, 0, sizeof(sa));

25:

26:  if (useDefault)

27:   sa.sa_handler = SIG_DFL;

28:  else

29:   sa.sa_handler = handler;

30:

31:  if (sigaction(sigNum, &sa, NULL)) perror("sigaction");

32: }

33:

34: int main() {

35:  catchSignal(SIGTSTP, 0);

36:  catchSignal(SIGCONT, 0);

37:

38:  while(1);

39:

40:  return 0;

41: }

 

Устройства tty предоставляют огромное количество опций обработки данных; они относятся к наиболее сложным устройствам ядра. Настраивать можно опции обработки входных и выходных данных, а также потока данных. Также можно контролировать ограниченное манипулирование данными на уровне драйвера устройства.

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

Режим обработки обрабатывает определенные управляющие символы; например, по умолчанию ^U уничтожает (стирает) текущую строку, ^W стирает текущее слово, забой (^Н) или Delete — предыдущий символ, a ^R стирает и затем повторно набирает текущую строку. Каждое из этих управляющих действий может быть повторно назначено другом символу. Например, на многих терминалах символу DEL (код 127) назначается действие забоя.

 

16.1.1. Служебные функции терминалов

Иногда невозможно узнать, соответствует ли файловый дескриптор tty. Чаще всего это связано со стандартным дескриптором выходного файла. Программы, выводящие текст на стандартные устройства, часто форматируются иначе при записи в канал, чем при отображении информации для пользователей. Например, в случае применения команды ls для получения списка файлов, она отобразит несколько колонок при простом запуске (удобнее читать человеку), но когда вы перенаправите ее вывод в другую программу, она отобразит по одному файлу в строке (удобнее читать программе). Запустите ls и ls | cat и почувствуйте разницу.

Определить, соответствует ли файловый дескриптор tty, можно с помощью функции isatty(), принимающей файловый дескриптор в качестве своего аргумента и возвращающей 1, если дескриптор соответствует tty, и 0 в противном случае.

#include

int isatty(int fd);

Функция ttyname() предоставляет каноническое имя для терминала, ассоциированное с файловым дескриптором. В качестве аргумента она принимает любой файловый дескриптор, возвращая указатель в поток символов.

#include

char *ttyname(int fd);

Поскольку поток символов расположен в статическом пространстве, потребуется сделать копию возвращенной строки перед повторным вызовом ttyname(); эта функция не реентерабельна. ttyname() возвращает NULL при любой ошибке, включая случай передачи файлового дескриптора, не ассоциированного с tty.

 

16.1.2. Управляющие терминалы

Каждый сеанс (см. главу 10) привязан к терминалу, с которого процессы сеанса получают свои входные данные и в который пересылают свои выходные данные. Этот терминал может быть локальной консолью машины, терминалом, подключенным через последовательный канал, либо псевдотерминалом, устанавливающим соответствия во внешнем окне или по всей сети (подробнее о псевдотерминалах читайте в конце этой главы). Терминал, к которому относится сеанс, называется управляющим терминалом (или управляющим tty) сеанса. Терминал может быть управляющим терминалом только в одном сеансе за раз.

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

Существуют два интерфейса для смены управляющего tty лидера сеанса. Первый реализуется с помощью нормальных системных вызовов open() и close().

1. Закройте все файловые дескрипторы, относящиеся к текущему управляющему терминалу.

2. Откройте новый терминал без установки флага O_NOCTTY.

Второй метод включает вызовы ioctl() на отдельных файловых дескрипторах, ссылающихся на старые и новые терминалы.

1. Установите флаг TIOCNOTTY на файловый дескриптор, привязанный к исходному управляющему tty (обычно ioctl(0, TIOCNOTTY, NULL) нормально работает). Это разрывает соединение между сеансом и tty.

2. Установите флаг TIOCSCTTY на файловый дескриптор, привязанный к новому управляющему tty. Это устанавливает новый управляющий tty.

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

Функция tcsetpgrp() позволяет процессу, работающему на терминале, сменить группу процессов переднего плана для этого терминала.

int tcsetpgrp(int ttyfd, pid_t pgrp);

Первый параметр определяет tty, управляющая группа процессов которого изменяется, a pgrp является группой процессов, которую необходимо переместить на передний план. Процессы могут менять группу процессов переднего плана только для своего управляющего терминала. Если процесс, совершающий изменение, не принадлежит к группе процессов переднего плана на этом терминале, генерируется сигнал SIGTTOU, если только он не игнорируется или заблокирован.

 

16.1.3. Принадлежность терминала

Существуют две системные базы данных, используемые для отслеживания зарегистрированных пользователей; utmp применяется для пользователей, зарегистрированных в данный момент, a wtmp является записью всех предыдущих регистраций со времени создания файла. Команда who использует базу данных utmp для отображения списка зарегистрированных пользователей, а команда last — базу данных wtmp для отображения списка пользователей, зарегистрированных в системе после регенерации базы данных wtmp. В системах Linux база данных utmp хранится в файле /var/run/utmp, а база данных wtmp — в файле /var/log/wtmp.

Программы, использующие tty для сеансов регистрации пользователей (независимо от того, ассоциируются ли они с графической регистрацией), должны обновлять эти две системные базы данных, пока пользователь явно не сделает иной запрос; например, некоторые пользователи не хотят, чтобы каждый сеанс оболочки, запускаемый ими в эмуляторе терминала в системе X Window, перечислялся как процесс входа. Добавляйте только интерактивные сеансы, поскольку utmp и wtmp не предназначены для регистрации автоматизированных программ. Любые tty, не являющиеся контролирующими терминалами, обычно в базы данных utmp и wtmp не добавляются.

 

16.1.4. Запись с помощью

utempter

Приложения со встроенными средствами безопасности, использующие pty, имеют недостаточно полномочий для модификации файлов баз данных. Эти приложения должны предоставлять опцию для использования простой вспомогательной программы, доступной в большинстве систем Linux и в некоторых других системах, но не стандартизованной — утилиты utempter. Утилита utempter является setgid (или, при необходимости, setuid) с достаточными полномочиями для модификации баз данных utmp и wtmp. Доступ к ней можно получить через простую библиотеку. Утилита utempter проверяет, владеет ли процесс tty, который пытается войти в базу данных utmp до разрешения операции, utempter предназначена только для pty; другие tty обычно открываются демонами с достаточными полномочиями для модификации файлов системных баз данных.

#include

void addToUtmp(const char *pty, const char *hostname, int ptyfd);

void removeLineFromUtmp(const char *pty, int ptyfd);

void removeFromUtmp(void);

Функция addToUtmp() принимает три аргумента. Первый, pty, является полным путем к добавляемому pty. Второй, hostname, может быть NULL или сетевым именем системы, из которой сетевое подключение использует этот порожденный pty (что запускает ut_host, рассматриваемый в следующем разделе главы). Третий, ptyfd, должен быть открытым файловым дескриптором, ссылающимся на устройство, названное в аргументе pty.

Функция removeLineFromUtmp() принимает два аргумента; они определяются в точности как аргументы с таким же именем, передаваемые функции addToUtmp().

Некоторые существующие приложения записываются с помощью структуры, усложняющей хранение имени и файлового дескриптора для очистки элемента utmp. Из-за этого библиотека utempter поддерживает кэш самого позднего имени устройства и файлового дескриптора, передаваемого addToUtmp(), и удобную функцию removeFromUtmp(), не принимающую никаких аргументов и действующую как removeLineFromUtmp() на кэшированную информацию. Это подходит только для приложений, добавляющих лишь один элемент utmp; более сложные приложения, использующие более одного pty, должны вместо этого применять removeLineFromUtmp().

 

16.1.5. Запись вручную

Область обработки utmp и wtmp является одной из тех противоречивых областей, где механизмы различаются между системами и меняются на протяжении лет; даже определение информации, доступной в utmp и wtmp, до сих пор различается между системами. Изначально utmp и wtmp были просто массивами структур, записанных на диск; через некоторое время были созданы программные интерфейсы приложений (API) для надежной обработки записей.

По крайней мере, два таких интерфейса были официально стандартизованы; исходный интерфейс utmp (описанный в XSI, XPG2 и SVID2) и расширенный интерфейс utmpx (описанный в XPG4.2 и в поздних версиях POSIX). В Linux доступны оба интерфейса (utmp и utmpx). Интерфейс utmp, широко варьирующийся между машинами, имеет набор определений, которые делают возможной запись переносимого кода. Этот код пользуется преимуществом расширений, предоставляемых glibc. Более строго стандартизованный интерфейс utmpx в данный момент не предоставляет эти определения, но все еще поддерживает расширения.

Интерфейс Linux utmp был изначально задуман как супермножество других существующих интерфейсов utmp, a utmpx был стандартизован как супермножество других существующих интерфейсов utmp; к счастью, оба набора во многом одинаковы. В Linux различие между структурами данных utmp и utmpx заключается лишь в букве x.

Если вы не хотите применять расширения, мы рекомендуем использовать интерфейс utmpx, поскольку он наиболее переносим, пока вы не используете расширения, и строго стандартизован.

Однако если вы хотите применять расширения, мы рекомендуем использовать интерфейс utmp, поскольку glibc предоставляет определения, позволяющие записать переносимый код, пользующийся преимуществами расширений.

Существует также смешанный подход — включите оба заголовочных файла и используйте определения, предоставляемые glibc для интерфейса utmp, чтобы решить, применять ли расширения в интерфейсе utmpx. Этого мы не рекомендуем, поскольку нет гарантии, что заголовочные файлы utmp.h и utmpx.h не будут конфликтовать с системами, не относящимися к Linux. Если ожидается максимальная переносимость и функциональность, в одной из этих областей придется записать некоторые коды дважды — первую версию с использованием utmpx для легкого переноса в новые системы, а вторую с применением #ifdef — для максимальной функциональности в каждой новой системе, в которую вы перемещаетесь.

Здесь документируются лишь наиболее распространенные расширения; документация glibc покрывает все поддерживаемые расширения. Функции utmp работают в терминах struct utmp; мы игнорируем некоторые расширения. Структура и функции utmpx работают точно так же, как структура и функции utmp, поэтому мы не документируем их отдельно. Обратите внимание, что такая же структура используется и для utmp, и для wtmp, поскольку обе базы данных очень похожи.

struct utmp {

 short int ut_type;          /* тип входа */

 pid_t ut_pid;               /* идентификатор процесса входа */

 char ut_line[UT_LINESIZE];  /* 32 символа */

 char ut_id[4];              /* идентификатор inittab */

 char ut_user[UT_NAMESIZE];  /* 32 символа */

 char ut_host[UT_HOSTSIZE];  /* 256 символов */

 struct timeval ut_tv;

 struct exit_status ut_exit; /* состояние бездействующего процесса */

 long ut_session;

 int32_t ut_addr_v6[4];

};

Многие одинаковые элементы являются частью struct utmpx под тем же именем. Элементы, от которых не требуется быть элементами struct utmpx, комментируются как "не стандартизованные POSIX" (ни один из них не стандартизован как часть struct utmp, поскольку сама struct utmp не стандартизована).

Элементы массива символов необязательно являются строками, завершающимися NULL. Используйте sizeof() либо другие ограничения размеров благоразумно.

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

Ниже приведены интерфейсы, определяемые XPG2, SVID 2 и FSSTND 1.2.

#include

int utmpname(char * file);

struct utmp *getutent(void);

struct utmp *getutid(const struct utmp * id);

struct utmp *getutline(const struct utmp * line);

struct utmp *pututline(const struct utmp * ut);

void setutent(void);

void endutent(void);

void updwtmp(const char * file, const struct utmp * ut);

void logwtmp(const char * line, const char * name, const char * host);

Каждая запись в базе данных utmp или wtmp называется строкой. Все функции, возвращающие указатель на struct utmp, возвращают его на статические данные в случае успеха и NULL — в случае ошибки. Обратите внимание, что статические данные переписаны каждым новым вызовом на каждую функцию, возвращающую struct utmp. Также стандарт POSIX (для utmpx) требует очистки статических данных приложением перед началом какого-либо поиска.

Версии utmpx этих функций принимают struct utmpx вместо struct utmp, требуют включения utmpx.h и называются getutxent, getutxid, getutxline, pututxline, setutxent и endutxent, но в другом случае они идентичны версиям utmp этих функций в Linux. Функции utmpxname(), определенной POSIX, не существует, хотя некоторые платформы могут определять ее в любом случае (например, glibc).

Функция utmpname() используется для определения просматриваемой базы данных. Базой данных по умолчанию является utmp, но вместо этого функцию можно применять для указания на wtmp. Два предопределенных имени — это _PATH_UTMP для файла utmp и _PATH_WTMP для файла wtmp; для целей тестирования можно выбрать указатель на локальную копию. Функция utmpname() возвращает ноль в случае успеха и ненулевое значение в случае ошибки. Но успех может означать просто то, что имя файла удалось скопировать в библиотеку; это не означает, что база данных действительно существует в пути, предоставленном для нее.

Функция getutent() просто возвращает следующую строку из базы данных. Если база данных еще не открыта, она возвращает содержимое первой строки. Если строки больше не доступны, она возвращает NULL.

Функция getutid() принимает struct utmp и рассматривает лишь один или два элемента. Если ut_type является BOOT_TIME, OLD_TIME или NEW_TIME, она возвращает следующую строку этого типа. Если ut_type является INIT_PROCESS, LOGIN_PROCESS, USER_PROCESS или DEAD_PROCESS, тогда getutid() возвращает следующую строку, которая соответствует любому из типов, также имеющему значение ut_id, которое соответствует значению ut_id в struct utmp, передаваемой getutid(). Перед повторным вызовом потребуется удалить из struct utmp данные, возвращаемые getutid(); POSIX разрешает возвращать ту же строку, что и предыдущий вызов. Если соответствующих строк нет, возвращается NULL.

Функция getutline() возвращает следующую строку с ut_id, установленным в LOGIN_PROCESS или USER_PROCESS. Эти процессы тоже имеют значение ut_line, соответствующее значению ut_line в struct utmp, которая передается в getutline(). Как и в случае getutid(), необходимо удалить данные, возвращаемые getutline(), из struct utmp перед его повторным вызовом; в противном случае POSIX разрешает возвращать ту же строку, что и предыдущий вызов. Если соответствующих строк нет, возвращается NULL.

Функция pututline() модифицирует (или по необходимости добавляет) запись базы данных, соответствующую элементу ut_line аргумента struct utmp. Она делает это только в том случае, если у процесса есть полномочия на модификацию базы данных. Если модификация базы данных прошла успешно, она возвращает struct utmp, который соответствует данным, записанным в базу. В ином случае возвращается NULL. Функция pututline() не применима к базе данных wtmp. Для модификации базы данных wtmp используйте updwtmp() или logwtmp().

Функция setutent() перемещает внутренний указатель базы данных в начало.

Функция endutent() закрывает базу данных. Это закрывает файловый дескриптор и освобождает ассоциированные данные. Вызывайте endutent() как перед использованием utmpname() для доступа к другому файлу utmp, так и после завершения доступа к данным utmp.

Наиболее надежным способом модификации базы данных wtmp являются две функции, определенные BSD и доступные как часть glibc.

Функция updwtmp() принимает файловое имя базы данных wtmp (обычно _PATH_WTMP) и заполненную структуру struct utmp, пытаясь добавить элемент к файлу wtmp. Эта функция не сообщает об ошибках.

Функция logwtmp() является удобной функцией, заполняющей struct utmp и вызывающей updwtmp() для нее. Аргумент line копируется в ut_line, name — в ut_user, host — в ut_host, ut_tv заполняется текущим показанием времени, a ut_pid — текущим идентификатором процесса. Как и updwtmp(), эта функция не сообщает об ошибках.

В программе utmp демонстрируются некоторые методы чтения баз данных utmp и wtmp.

  1: /* utmp.с */

  2:

  3: #include

  4: #include

  5: #include

  6: #include

  7: #include

  8: #include

  9: #include

 10: #include

 11: #include

 12: #include

 13: #include

 14:

 15: void print_utmp_entry(struct utmp * u) {

 16:  struct tm *tp;

 17:  char * type;

 18:  char addrtext[INET6_ADDRSTRLEN];

 19:

 20:  switch (u->ut_type) {

 21:  case EMPTY: type = "EMPTY"; break;

 22:  case RUN_LVL: type = "RUN_LVL"; break;

 23:  case BOOT_TIME: type = "BOOT_TIME"; break;

 24:  case NEW_TIME: type = "NEW_TIME"; break;

 25:  case OLD_TIME: type = "OLD_TIME"; break;

 26:  case INIT_PROCESS: type = "INIT_PROCESS"; break;

 27:  case LOGIN_PROCESS: type = "LOGIN_PROCESS"; break;

 28:  case USER_PROCESS: type = "USER_PROCESS"; break;

 29:  case DEAD_PROCESS: type = "DEAD_PROCESS"; break;

 30:  case ACCOUNTING: type = "ACCOUNTING "; break;

 31:  }

 32:  printf("%-13s:", type);

 33:  switch (u->ut_type) {

 34:  case LOGIN_PROCESS:

 35:  case USER_PROCESS:

 36:  case DEAD_PROCESS:

 37:   printf(" line: %s", u->ut_line);

 38:   /* fall through */

 39:  case INIT_PROCESS:

 40:   printf("\n pid: %6d id: %4.4s", u->ut_pid, u->ut_id);

 41:  }

 42:  printf ("\n");

 43:  tp = gmtime(&u->ut_tv.tv_sec);

 44:  printf("time: %24.24s.%lu\n", asctime(tp), u->ut_tv.tv_usec);

 45:  switch (u->ut_type) {

 46:  case USER_PROCESS:

 47:  case LOGIN_PROCESS:

 48:  case RUN_LVL:

 49:  case BOOT_TIME:

 50:   printf("пользователь: %s\n", u->ut_user);

 51:  }

 52:  if (u->ut_type == USER_PROCESS) {

 53:   if (u->ut_session)

 54:    printf(" сеанс: %lu\n", u->ut_session);

 55:   if (u->ut_host)

 56:    printf (" хост: %s\n", u->ut_host);

 57:   if (u->ut_addr_v6[0]) {

 58:    if (!(u->ut_addr_v6[1] |

 59:     u->ut_addr_v6[2] |

 60:     u->ut_addr_v6[3])) {

 61:     /* заполнение только первой группы означает адрес IPV4 */

 62:     inet_ntop(AF_INET, u->ut_addr_v6,

 63:     addrtext, sizeof(addrtext));

 64:     printf(" IPV4: %s\n", addrtext);

 65:    } else {

 66:     inet_ntop(AF_INET_6, u->ut_addr_v6,

 67:      addrtext, sizeof(addrtext));

 68:     printf (" IPV6: %s\n", addrtext);

 69:    }

 70:   }

 71:  }

 72:  if (u->ut_type == DEAD_PROCESS) {

 73:   printf(" завершение : %u: %u\n",

 74:    u->ut_exit.e_termination,

 75:    u->ut_exit.e_exit);

 76:  }

 77:  printf("\n");

 78: }

 79:

 80: struct utmp * get_next_line (char * id, char * line) {

 81:  struct utmp request;

 82:

 83:  if (!id && !line)

 84:   return getutent();

 85:

 86:  memset(&request, 0, sizeof(request));

 87:

 88:  if (line) {

 89:   strncpy(&request.ut_line[0], line, UT_LINESIZE);

 90:   return getutline(&request);

 91:  }

 92:

 93:  request.ut_type = INIT_PROCESS;

 94:  strncpy(&request.ut_id[0], id, 4);

 95:  return getutid(&request);

 96: }

 97:

 98: void print_file(char * name, char * id, char * line) {

 99:  struct utmp * u;

100:

101:  if (utmpname(name)) {

102:   fprintf (stderr, "сбой при открытии базы данных utmp %s\n", name);

103:   return;

104:  }

105:  setutent();

106:  printf("%s:\n====================\n", name);

107:  while ((u = get_next_line(id, line))) {

108:   print_utmp_entry(u);

109:   /* POSIX требует очистки статических данных перед

110:    * повторным вызовом getutline или getutid

111:    */

112:   memset(u, 0, sizeof(struct utmp));

113:  }

114:  endutent();

115: }

116:

117: int main(int argc, const char **argv) {

118:  char * id = NULL, *line = NULL;

119:  int show_utmp = 1, show_wtmp = 0;

120:  int c;

121:  poptContext optCon;

122:  struct poptOption optionsTable[] = {

123:   {"utmp", 'u', POPT_ARG_NONE|POPT_ARGFLAG_XOR,

124:    &show_utmp, 0,

125:    "переключить просмотр содержимого файла utmp", NULL},

126:   { "wtmp", 'w', POPT_ARG_NONE | POPT_ARGFLAG_XOR,

127:     &show_wtmp, 0,

128:     "переключить просмотр содержимого файла wtmp", NULL},

129:   {"id", 'i', POPT_ARG_STRING, &id, 0,

130:    "показать записи процесса для заданного идентификатора inittab",

131:    "" },

132:   {"line", 'l', POPT_ARG_STRING, &line, 0,

133:    "показать записи процесса для заданной строки устройства",

134:    "" },

135:   POPT_AUTOHELP

136:   POPT_TABLEEND

137:  };

138:

139:  optCon = poptGetContext("utmp", argc, argv, optionsTable, 0);

140:  if ((c = poptGetNextOpt(optCon)) < -1) {

141:   fprintf(stderr, "%s:%s\n",

142:    poptBadOption(optCon, POPT_BADOPTION_NOALIAS),

143:    poptStrerror(c));

144:   return 1;

145:  }

146:  poptFreeContext(optCon);

147:

148:  if (id && line)

149:   fprintf(stderr, "Невозможно выбирать сразу по идентификатору и строке,"

150:    "выбор по строке\n");

151:

152:  if (show_utmp)

153:   print_file(_PATH_UTMP, id, line);

154:  if (show_utmp && show_wtmp)

155:   printf("\n\n\n");

156:  if (show_wtmp)

157:   print_file(_PATH_WTMP, id, line);

158:

159:  return 0;

160: }

 

16.3.1. Пароли

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

struct termios ts, ots;

Первая структура хранит оригинальные установки для восстановления, а вторая является копией для модификации.

tcgetattr(STDIN_FILENO, &ts);

Обычно пароли читаются со стандартного устройства ввода.

ots = ts;

Сохраните копию оригинальных установок termios, чтобы позже восстановить их.

ts.c_lflag &= ~ECHO;

ts.c_lflag |= ECHONL;

tcsetattr(STDIN_FILENO, TCSAFLUSH, fits);

Отключите эхо-контроль символов (кроме символов новой строки) после завершения обработки всех выходных данных. (Первая l в c_lflag означает локальную (local) обработку.)

read_password();

Теперь вы читаете пароль. Это может быть простой вызов fgets() или read(), либо же более сложная обработка, в зависимости от режима tty (неформатируемый режим или режим обработки) и от требований программы.

tcsetattr(STDIN_FILENO, TCSANOW, &ots);

Это немедленно восстанавливает исходные установки termios. (Остальные опции объясняются позже, в справочном разделе далее в главе.)

Полный код программы-примера, readpass, показан ниже.

 1: /* readpass.с */

 2:

 3: #include

 4: #include

 5: #include

 6: #include

 7:

 8: int main (void) {

 9:  struct termios ts, ots;

10:  char passbuf[1024];

11:

12:  /* получить и сохранить текущие настройки termios */

13:  tcgetattr(STDIN_FILENO, &ts);

14:  ots = ts;

15:

16:  /* изменить и установить новые настройки termios */

17:  ts.c_lflag & = ~ECHO;

18:  ts.c_lflag |= ECHONL;

19:  tcsetattr(STDIN_FILENO, TCSAFLUSH, &ts);

20:

21:  /*хоть это и параноидально, но проверить, возымели ли эффект новые настройки*/

22:  tcgetattr(STDIN_FILENO, &ts);

23:  if (ts.c_lflag & ECHO) {

24:   fprintf(stderr, "Сбой при отключении эхо-контроля\n");

25:   tcsetattr(STDIN_FILENO, TCSANOW, &ots);

26:   exit(1);

27:  }

28:

29:  /* получить и вывести пароль */

30:  printf("введите пароль:");

31:  fflush(stdout);

32:  fgets(passbuf, 1024, stdin);

33:  printf("прочитан пароль: %s", passbuf);

34:  /* в passbuf был завершающий символ \n */

35:

36:  /* восстановить старые настройки termios */

37:  tcsetattr(STDIN_FILENO, TCSANOW, &ots);

38:

39:  exit(0);

40: }

 

16.3.2. Последовательные коммуникации

В качестве примера программирования обоих концов tty рассмотрим программу, подключающую текущий терминал к последовательному порту. На одном tty программа под названием robin сообщается с вами во время набора. На другом tty она взаимодействует с последовательным портом. С целью мультиплексирования вводных и выходных данных на локальном tty и последовательном порте программа использует системный вызов poll(), описанный в главе 13.

Ниже приведен полный код программы robin.с, за которым даны объяснения.

  1: /* robin.с */

  2:

  3: #include

  4: #include

  5: #include

  6: #include

  7: #include

  8: #include

  9: #include

 10: #include /* для strerror() */

 11: #include

 12: #include

 13:

 14: void die(int exitcode, const char *error, const char *addl) {

 15:  if (error) fprintf(stderr, "%s: %s\n", error, addl);

 16:  exit(exitcode);

 17: }

 18:

 19: speed_t symbolic_speed(int speednum) {

 20:  if (speednum >= 460800) return B460800;

 21:  if (speednum >= 230400) return B230400;

 22:  if (speednum >= 115200) return B115200;

 23:  if (speednum >= 57600) return B57600;

 24:  if (speednum >= 38400) return B38400;

 25:  if (speednum >= 19200) return B19200;

 26:  if (speednum >= 9600) return B9600;

 27:  if (speednum >= 4800) return B4800;

 28:  if (speednum >= 2400) return B2400;

 29:  if (speednum >= 1800) return B1800;

 30:  if (speednum >= 1200) return B1200;

 31:  if (speednum >= 600) return B600;

 32:  if (speednum >= 300) return B300;

 33:  if (speednum >= 200) return B200;

 34:  if (speednum >= 150) return B150;

 35:  if (speednum >= 134) return B134;

 36:  if (speednum >= 110) return B110;

 37:  if (speednum >= 75) return B75;

 38:  return B50;

 39: }

 40:

 41: /* Это нужно для области видимости в пределах файла, так что

 42:  * их можно будет использовать в обработчиках сигналов */

 43: /* старые настройки порта termios для восстановления */

 44: static struct termios pots;

 45: /* старые настройки stdout/stdin termios для восстановления */

 46: static struct termios sots;

 47: /* файловый дескриптор порта */

 48: int pf;

 49:

 50: /* восстановить первоначальные настройки терминала при выходе */

 51: void cleanup_termios(int signal) {

 52:  tcsetattr(pf, TCSANOW, &pots);

 53:  tcsetattr(STDIN_FILENO, TCSANOW, &sots);

 54:  exit(0);

 55: }

 56:

 57: /* обработать одиночный управляющий символ */

 58: void send_escape(int fd, char c) {

 59:  switch (c) {

 60:  case 'q':

 61:   /* восстановить настройки termios и выйти */

 62:   cleanup_termios(0);

 63:   break;

 64:  case 'b':

 65:   /* послать символ разрыва*/

 66:   tcsendbreak(fd, 0);

 67:   break;

 68:  default:

 69:   /* пропустить символ */

 70:   /* "C-\ C-\" sends "C-\" */

 71:   write(fd, &c, 1);

 72:   break;

 73:  }

 74:  return;

 75: }

 76:

 77: /* обработать управляющие символы, записывая их в вывод */

 78: void cook_buf(int fd, char * buf, int num) {

 79:  int current = 0;

 80:  static int in_escape = 0;

 81:

 82:  if (in_escape) {

 83:   /* cook_buf последний раз вызывался с незавершенной

 84:      управляющей последовательностью */

 85:   send_escape(fd, buf[0]);

 86:   num--;

 87:   buf++;

 88:   in_escape = 0;

 89:  }

 90:  while (current < num) {

 91: # define CTRLCHAR(c) ((c)-0x40)

 92:   while ((current < num) && (buf[current] != CTRLCHAR('W')))

 93:    current++;

 94:   if (current) write (fd, buf, current);

 95:   if (current < num) {

 96:    /* найден управляющий символ */

 97:    current++;

 98:    if (current >= num) {

 99:     /*интерпретировать первый символ следующей последовательности*/

100:     in_escape = 1;

101:     return;

102:    }

103:    send_escape(fd, buf[current]);

104:   }

105:   num -= current;

106:   buf += current;

107:   current = 0;

108:  }

109:  return;

110: }

111:

112: int main(int argc, const char * argv[]) {

113:  char с; /* используется для разбора аргументов */

114:  struct termios pts; /* настройки termios для порта */

115:  struct termios sts; /* настройки termios для stdout/stdin */

116:  const char *portname;

117:  int speed = 0; /* используется при разборе аргументов для скорости */

118:  struct sigaction sact; /* используется для инициализации обработчика сигналов */

119:  struct pollfd ufds[2]; /* взаимодействие с poll() */

120:  int raw = 0; /* неформатированный режим? */

121:  int flow = 0; /* тип управления потоком, если применяется*/

122:  int crnl = 0; /* посылать ли символ возврата каретки с символом новой строки? */

123:  int i = 0; /* используется в цикле мультиплексирования*/

124:  int done = 0; 125: # define BUFSIZE 1024

126:  char buf[BUFSIZE];

127:  poptContext optCon; /* контекст опций командной строки */

128:  struct poptOption optionsTable[] = {

129:   { "bps", 'b', POPT_ARG_INT, &speed, 0,

130:     "скорость передачи сигналов, бит/с",

131:     "" },

132:   { "crnl", 'с', POPT_ARG_VAL, &crnl, 'с',

133:     "посылать символ возврата каретки с символом новой строки", NULL },

134:   { "hwflow", 'h', POPT_ARG_VAL, &flow, 'h',

135:     "использовать аппаратное управление потоком", NULL },

136:   { "swflow", 's', POPT_ARG_VAL, &flow, 's',

137:     "использовать программное управление потоком", NULL },

138:   { "noflow", 'n', POPT_ARG_VAL, &flow, 'n',

139:     "отключить управление потоком", NULL },

140:   { "raw", 'r', POPT_ARG_VAL, &raw, 1,

141:     "включить неформатированный режим", NULL },

142:   POPT_AUTOHELP

143:   { NULL, '\0', 0, NULL, '\0', NULL, NULL }

144:  };

145:

146: #ifdef DSLEEP

147:  /* ожидать 10 минут, что позволить подключить отладчик */

148:  sleep(600);

149: #endif

150:

151:  optCon = poptGetContext("robin", argc, argv, optionsTable, 0);

152:  poptSetOtherOptionHelp(optCon, "");

153:

154:  if (argc < 2) {

155:   poptPrintUsage(optCon, stderr, 0);

156:   die(1, "He достаточно аргументов", "");

157:  }

158:

159:  if ((с = poptGetNextOpt(optCon)) < -1) {

160:   /* ошибка во время обработки опций */

161:   fprintf(stderr, "%s: %s\n",

162:    poptBadOption(optCon, POPT_BADOPTION_NOALIAS),

163:    poptStrerror(c));

164:   return 1;

165:  }

166:  portname = poptGetArg(optCon);

167:  if (!portname) {

168:   poptPrintUsage(optCon, stderr, 0);

169:   die(1, "He указано имя порта", "");

170:  }

171:

172:  pf = open(portname, O_RDWR);

173:  if (pf < 0) {

174:   poptPrintUsage(optCon, stderr, 0);

175:   die(1, strerror(errno), portname);

176:  }

177:  poptFreeContext(optCon);

178:

179:  /* изменить конфигурацию порта */

180:  tcgetattr(pf, &pts);

181:  pots = pts;

182:  /* некоторые настройки устанавливаются произвольно */

183:  pts.c_lflag &= ~ICANON;

184:  pts.c_lflag &= ~(ECHO | ECHOCTL | ECHONL);

185:  pts.c_cflag |= HUPCL;

186:  pts.c_cc[VMIN] = 1;

187:  pts.c_cc[VTIME] = 0;

188:

189:  /* Стандартная обработка CR/LF: это неинтеллектуальный терминал.

190:   * Не транслируется:

191:   * нет NL -> отображение CR/NL в выводе,

192:   * нет CR -> отображение NL во вводе.

193:   */

194:  pts.c_oflag &= ~ONLCR;

195:  pts.c_iflag &= ~ICRNL;

196:

197:  /* Теперь перейти на сторону локального терминала */

198:  tcgetattr(STDIN_FILENO, &sts);

199:  sots = sts;

200:  /* и снова несколько произвольных настроек */

201:  sts.c_iflag &= ~(BRKINT | ICRNL);

202:  sts.c_iflag |= IGNBRK;

203:  sts.c_lflag &= ~ISIG;

204:  sts.c_cc[VMIN] = 1;

205:  sts.c_cc[VTIME] = 0;

206:  sts.c_lflag &= ~ICANON;

207:  /* нет локального эхо: разрешить эхо-контроль на другом конце */

208:  sts.c_lflag &= ~(ECHO | ECHOCTL | ECHONL);

209:

210:  /* обработка опций сейчас будет модифицировать pts и sts */

211:  switch (flow) {

212:  case 'h' :

213:   /* аппаратное управление потоком */

214:   pts.c_cflag |= CRTSCTS;

215:   pts.c_iflag &= ~(IXON | IXOFF | IXANY);

216:   break;

217:  case 's':

218:   /* программное управление потоком */

219:   pts.c_cflag &= ~CRTSCTS;

220:   pts.c_iflag |= IXON | IXOFF | IXANY;

221:   break;

222:  case 'n':

223:   /* отключение управления потоком */

224:   pts.c_cflag &= ~CRTSCTS;

225:   pts.c_iflag &= ~(IXON | IXOFF | IXANY);

226:   break;

227:  }

228:  if (crnl) {

229:   /* послать CR с NL */

230:   pts.c_oflag |= ONLCR;

231:  }

232:

233:  /* скорость не изменяется, пока не будет указано -b */

234:  if (speed) {

235:   cfsetospeed(&pts, symbolic_speed(speed));

236:   cfsetispeed(&pts, symbolic_speed(speed));

237:  }

238:

239:  /* установить обработчик сигналов для восстановления

240:   * старого обработчика termios */

241:  sact.sa_handler = cleanup_termios;

242:  sigaction(SIGHUP, &sact, NULL);

243:  sigaction(SIGINT, &sact, NULL);

244:  sigaction(SIGPIPE, &sact, NULL);

245:  sigaction(SIGTERM, &sact, NULL);

246:

247:  /* установить измененные настройки termios */

248:  tcsetattr(pf, TCSANOW, &pts);

249:  tcsetattr(STDIN_FILENO, TCSANOW, &sts);

250:

251:  ufds[0].fd = STDIN_FILENO;

252:  ufds[0].events = POLLIN;

253:  ufds[1].fd = pf;

254:  ufds[1].events = POLLIN;

255:

256:  do {

257:   int r;

258:

259:   r = poll(ufds, 2, -1);

260:   if ((r < 0) && (errno != EINTR))

261:    die(1, "неожиданный сбой poll", "");

262:

263:   /* сначала проверить возможность завершения */

264:   if ((ufds[0].revents | ufds[1].revents) &

265:    (POLLERR | POLLHUP | POLLNVAL)) {

266:    done = 1;

267:    break;

268:   }

269:

270:   if (ufds[1].revents & POLLIN) {

271:    /* pf содержит символы */

272:    i = read (pf, buf, BUFSIZE);

273:    if (i >= 1) {

274:     write(STDOUT_FILENO, buf, i);

275:    } else {

276:     done = 1;

277:    }

278:   }

279:   if (ufds[0].revents & POLLIN) {

280:    /* стандартный ввод содержит символы */

281:    i = read(STDIN_FILENO, buf, BUFSIZE);

282:    if (i >= 1) {

283:     if (raw) {

284:      write(pf, buf, i);

285:     } else {

286:      cook_buf(pf, buf, i);

287:     }

288:    } else {

289:     done = 1;

290:    }

291:   }

292:  } while (!done);

293:

294:  /* восстановить первоначальные настройки терминала и завершиться*/

295:  tcsetattr(pf, TCSANOW, &pots);

296:  tcsetattr(STDIN_FILENO, TCSANOW, &sots);

297:  exit(0);

298: }

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

Функция symbolic_speed() в строке 19 преобразует целочисленную скорость в символическую, которую поддерживает termios. К сожалению, termios не предназначен для работы с произвольными скоростями, так что каждая скорость, которую вы хотите использовать, должна быть частью интерфейса пользователь — ядро.

Обратите внимание, что предусмотрены и довольно высокие скорости. Не все последовательные порты поддерживают скорости 230 400 или 460 800 бит/с; в стандарте POSIX определены скорости лишь до 38 400 бит/с. Чтобы сделать эту программу переносимой, каждую строку над строкой, в которой устанавливается скорость 38 400 бит/с, потребуется расширить до трех строк, как показано ниже:

#ifdef В460800

if (speednum >= 460800) return B46000;

#end if

Это позволит пользователям устанавливать скорости выше тех, которые последовательные порты способны поддерживать, а исходный код теперь будет компилироваться в любой системе с POSIX termios. (Как упоминалось ранее в этой главе, любой последовательный порт может отказаться принять на обработку любую установку termios, которую он не способен поддержать, включая также установки скорости. Поэтому установка B460800 не означает, что можно установить скорость порта равной 460 800 бит/с.)

В строках 44—55 определяются глобальные переменные для передачи некоторых переменных обработчику сигналов и сам обработчик сигналов. Обработчик сигналов предназначен для восстановления настроек termios на обоих интерфейсах tty при доставке сигнала, поэтому ему необходимо получить доступ к структурам, содержащим старые настройки termios. Ему также необходимо знать файловый дескриптор или последовательный порт (файловый дескриптор для стандартных входных данных не меняется, поэтому компилируется в бинарный). Этот код идентичен коду в случае нормального пути завершения, который рассматривается позже. Обработчик сигналов затем прикрепляется к сигналам, которые завершат процесс, если они были проигнорированы.

Функции send_escape() и cook_buf() будут рассматриваться позже. Они используются как часть обработки входных данных в цикле ввода-вывода в конце функции main().

Условно скомпилированный sleep(600) в начале функции main() предназначен для отладки. С целью отладки программ, модифицирующих настройки termios для стандартных входных или выходных данных, лучше всего присоединить процесс в другой окне или терминальном сеансе. Однако это означает, что нельзя установить точку прерывания на основную функцию и проходить по одной инструкции за раз. Необходимо запустить программу, найти идентификатор ее процесса и присоединиться к ней из отладчика. Более подробно этот процесс описан далее в настоящей главе.

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

Игнорируя отладку, мы в первую очередь анализируем опции, используя библиотеку popt, описанную в главе 26, а затем открываем последовательный порт, с которым будем взаимодействовать.

Затем мы вызываем функцию tcgetattr(), чтобы получить существующую конфигурацию termios последовательного порта, а затем сохраняем копию в pots, чтобы восстановить ее по окончании.

Начиная со строки 183, мы модифицируем установки последовательного порта:

183: pts.c_lflag &= ~ICANON;

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

184: pts.c_lflag &= ~(ECHO | ECHOCTL | ECHONL);

Это отключает локальный эхо-контроль в последовательном порте:

185: pts.c_cflag |= HUPCL;

Если подключен модем, HUPCL сообщает ему об отбое при закрытии устройства конечной программой:

186: pts.с_сс[VMIN] = 1;

187: pts.с_сс[VTIME] = 0;

Когда tty находится в неформатируемом режиме, эти две установки определяют поведение системного вызова read(). Эта особая установка сообщает, что при вызове read() мы хотим, чтобы он подождал с возвратом, пока не считаются один или несколько байтов. Мы никогда не вызовем read(), пока не будем знать, что остался хотя бы один байт для чтения, потому это функциональный эквивалент неблокирующего read(). Определение VMIN и VTIME сложное, как показано далее в настоящей главе.

Настройки termios по умолчанию включают преобразование некоторых символов в конце строки. Это подходит для модемных линий и терминальных сеансов, но при соединении двух tty повтор преобразования нежелателен. Нежелательно отображать символы новой строки на пару "возврат каретки/перевод строки" при выводе, а также принимаемый возврат каретки — на перевод строки при вводе, поскольку мы уже получаем пары "возврат каретки/перевод строки" с удаленной системы.

194: pts.c_oflag &= ~ONLCR;

195: pts.c_iflag &= ~ICRNL;

Без этих двух строк использование программы robin для соединения с другим компьютером Linux или Unix приведет к тому, что удаленная система увидит, что вы нажимаете клавишу дважды всякий раз, когда вы нажимаете ее один раз. И всякий раз, когда она будет пытаться отобразить новую строку на вашем экране, вы будете видеть две строки. Поэтому каждый раз при нажатии (предполагая, что у вас получится зарегистрироваться в этих установках терминала) вы увидите отраженные подсказки. Если же вы запустите vi, то увидите символы ~, расположенные через строку, а не в каждой строке.

Таким образом, мы внесли в настройки termios все изменения, которые необходимо сделать перед обработкой аргументов командной строки. Теперь приступим к модификации настроек tty, предоставляющего стандартные входные и выходные данные. Поскольку это один tty, необходимо обработать лишь один файловый дескриптор из пары. Мы отдали предпочтение стандартному вводу, выбрав соглашение, установленное программой stty. И снова все начинается с получения и сохранения атрибутов.

Затем потребуется модифицировать несколько флагов:

201: sts.c_iflag &= ~(BRKINT | ICRNL);

202: sts.c_iflag |= IGNBRK;

203: sts.c_lflag &= ~ISIG;

Отключение BRKINT играет роль только в том случае, если robin вызывается из регистрационного сеанса, присоединенного к другому последовательному порту, на котором можно получить разрыв. Его отключение означает, что драйвер tty не посылает SIGINT в robin, когда в стандартном устройстве ввода robin возникает разрыв, поскольку robin не может сделать ничего полезного при получении разрыва. Отключение ICRNL предотвращает сообщение в robin о любых символах возврата каретки ('\r') как о символах новой строки ('\n'). Как и при отключении BRKINT это действует лишь тогда, когда сеанс регистрации присоединяется к другому последовательному порту. Также это действует тогда, когда символы возврата каретки не игнорируются (то есть если не установлен флаг IGNCR).

Функция IGNBRK заставляет драйвер tty игнорировать разрывы. Включение IGNBRK будет здесь излишним. При установке IGNBRK игнорируется BRKINT. Но не беда, если вы установите обе функции.

Это флаги обработки входных данных. Также модифицируется локальный флаг обработки: отключается ISIG. Это предотвращает драйвер tty от передачи SIGINT, SIGQUIT и SIGTSTP при получении соответствующего символа (INTR, QUIT или SUSP). Мы делаем это потому, что хотим переслать эти символы на удаленную систему (или на другое устройство, подключенное к последовательному порту) для последующей обработки там.

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

По умолчанию мы оставляем последовательный порт в том состоянии управления потоком, в котором мы его находим. Однако в строке 212 есть опции аппаратного управления потоком (использующего управляющие провода CTS и RTS), программного управления потоком (резервирование ^S и ^Q для STOP и START соответственно) и полного отключения управления потоком.

212: case 'h':

213:  /* аппаратное управление потоком */

214:  pts.c_cflag |= CRTSCTS;

215:  pts.c_iflag &= ~(IXON | IXOFF | IXANY);

216:  break;

217: case 's' :

218:  /* программное управление потоком */

219:  pts.c_cflag &= ~CRTSCTS;

220:  pts.c_iflag |= IXON | IXOFF | IXANY;

221:  break;

222: case 'n':

223:  /* отключение управления потоком */

224:  pts.q._cflag &= ~CRTSCTS;

225:  pts.c_iflag &= ~(IXON | IXOFF | IXANY);

226:  break;

Обратите внимание, что программное управление потоком включает три флага.

Когда другая программа использует robin как вспомогательную, может помешать обработка спецсимволов (robin обычно интерпретирует последовательность ^\), поэтому во избежание такой обработки устанавливается неформатируемый режим. В строке 120 мы предоставляем переменную, определяющую, включен ли неформатируемый режим; по умолчанию этот режим не включается. В строке 140 мы сообщаем popt о том, как информировать, когда в командной строке была указана опция -r или -raw, включающая неформатируемый режим.

Некоторые системы требуют передачи им символа возврата каретки для представления новой строки. Слово "системы" здесь следует понимать буквально; например, это применимо ко многим интеллектуальным периферийным устройствам, например, источникам бесперебойного питания (UPS) с последовательными портами, поскольку они предназначены для функционирования в DOS, где пара "возврат каретки/перевод строки" всегда используется для обозначения новой строки. В строке 228 определяется это DOS-ориентированное поведение.

228: if (crnl) {

229:  /* послать CR с NL */

230:  pts.c_oflag |= ONLCR;

231: }

Последняя часть обработки опций управляет скоростью передачи в битах в секунду. Вместо включения огромного вложенного оператора выбора мы вызываем уже описанную ранее функцию symbolic_speed(), чтобы получить speed_t, понимаемый termios, как показано в строке 233.

233: /* скорость не изменяется, пока не будет указано -b */

234: if (speed) {

235:  cfsetospeed(&pts, symbolic_speed(speed));

236:  cfsetispeed(&pts, symbolic_speed(speed));

237: }

Перед тем, как зафиксировать изменения наших копий структур termios, в строке 241 регистрируются обработчики для важных сигналов, которые могут в противном случае вызвать уничтожение процесса и оставить tty в неформатируемом состоянии. Более подробно обработчики сигналов рассматриваются в главе 12.

241: sact.sa_handler = cleanup_termios;

242: sigaction(SIGHUP, &sact, NULL);

243: sigaction(SIGINT, &sact, NULL);

244: sigaction(SIGPIPE, &sact, NULL);

245: sigaction(SIGTERM, &sact, NULL);

Как только обработчик сигналов окажется на месте для восстановления старых настроек termios в случае уничтожения robin, мы можем благополучно обновить установки termios.

248: tcsetattr(pf, TCSANOW, &pts);

249: tcsetattr(STDIN_FILENO, TCSANOW, &sts);

На этом этапе программа robin готова читать и записывать символы. У robin есть два файловых дескриптора для чтения: данные с последовательного порта и данные с клавиатуры. Для мультиплексирования ввода-вывода между четырьмя файловыми дескрипторами используется poll() (см. главу 13).

Цикл poll() делает упрощенческое предположение о том, что он всегда может записать столько, сколько в состоянии прочитать. Это почти всегда верно и не вызывает проблем на практике, поскольку блокирование на короткие периоды незаметно при нормальных условиях. Цикл никогда не считывает из файлового дескриптора, пока poll() не сообщит, что файловый дескриптор ожидает считывания данных, чтобы мы знали, что блокировки во время чтения нет.

Для данных, поступающих с клавиатуры, может понадобиться обработка управляющих последовательностей перед записью, если пользователь не выбрал неформатируемый режим при запуске robin. Вместо включения этого кода в цикл мы вызываем функцию cook_buf() (строка 78), которая при необходимости обращается к send_escape() (строка 58). Обе эти функции просты. Единственный трюк состоит в том, что cook_buf() может быть вызвана один раз с управляющим символом, а затем второй раз с интерпретируемым символом, а также в оптимизации количества вызовов функции write().

Функция cook_buf() вызывает функцию send_escape() один раз для каждого символа, которому предшествует неотменяемый управляющий символ ^\. Символ q восстанавливает исходные установки termios и завершается вызовом обработчика сигнала (с фальшивым номером сигнала 0), что восстанавливает настройки termios перед выходом. Символ b генерирует состояние разрыва, которое является длинной строкой, состоящей из нулей. Любой другой символ, включая второй управляющий символ ^\, передается в последовательный порт без изменений.

Если какой-то из входных файловых дескрипторов вернет признак конца файла, robin выходит из цикла poll() и передает управление обработке завершения, что соответствует обработчику сигнала: восстановление старых настроек termios на обоих входных файловых дескрипторов и завершение. В неформатируемом режиме существует только два способа завершения robin: закрыть один из файловых дескрипторов или передать ей сигнал.