Майкл Джонсон - Разработка приложений в среде Linux. Второе издание

В процессе работы system()блокирует SIGCHILD, что заставляет передавать этот сигнал программе непосредственно перед тем, как system()вернет управление (но после того, как system()вызовет wait()для порожденного процесса), поэтому программы, которые используют обработчики сигналов, должны это учитывать и обрабатывать такие ложные сигналы осторожно. Функция system()также игнорирует SIGINTи SIGQUIT, а это означает, что быстрые циклические повторные вызовы system()может оказаться невозможно прервать ничем, кроме SIGSTOPи SIGKILL.

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

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

Если вам понадобится делать это, запустите дочерний процесс с помощью fork()и exec(), а потом воспользуйтесь poll()для чтения и записи в дочерний процесс. Для этого предназначена программа под названием expect.

Информацию о чтении и записи в поток stdioможно найти в [15].

В главе 15 все это проясняется, поэтому, возможно, будет полезно сначала прочитать ее.

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

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

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

Не все блочные устройства представляют реальное оборудование. Более правильное описание блочных устройств — это нечто, на чем может располагаться файловая система; блочное устройство обратной связи (loopback block device) отображает на обычный файл логическое блочное устройство, что позволяет файлам содержать в себе целые файловые системы.

Точнее говоря, они кэшируются и доступ к ним упорядочен.

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

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

Это режим, обычно используемый для каталога /tmp.

readv(), writev()и mmap()обсуждаются в главе 13; sendmsg()и recvmsg()упоминаются в главе 17.

Хотя такое разделение почти ясно, сокеты TCP поддерживают "внеполосные" данные, что несколько усложняет ситуацию. Такие данные выходят за пределы тем, рассматриваемых в этой книге. Их полное описание можно найти в [33].

Почти независимую; см. описание исключений из этого правила в дискуссии о dup()в конце этой главы.

Поскольку в большинстве систем SEEK_SETопределена как 0, часто можно увидеть использование lseek(fd, offset, 0)вместо lseek(fd, offset, SEEK_SET). Это делает код непереносимым (или плохо читабельным), чем SEEK_SET, но подобное часто встречается в старом коде.