Майкл Джонсон - Разработка приложений в среде Linux. Второе издание
- Название:Разработка приложений в среде Linux. Второе издание
- Автор:
- Жанр:
- Издательство:Вильямс
- Год:2007
- Город:Москва
- ISBN:978-5-8459-1143-8
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Майкл Джонсон - Разработка приложений в среде Linux. Второе издание краткое содержание
Книга известных профессионалов в области разработки коммерческих приложений в Linux представляет собой отличный справочник для широкого круга программистов в Linux, а также тех разработчиков на языке С, которые перешли в среду Linux из других операционных систем. Подробно рассматриваются концепции, лежащие в основе процесса создания системных приложений, а также разнообразные доступные инструменты и библиотеки. Среди рассматриваемых в книге вопросов можно выделить анализ особенностей применения лицензий GNU, использование свободно распространяемых компиляторов и библиотек, системное программирование для Linux, а также написание и отладка собственных переносимых библиотек. Изобилие хорошо документированных примеров кода помогает лучше усвоить особенности программирования в Linux.
Книга рассчитана на разработчиков разной квалификации, а также может быть полезна для студентов и преподавателей соответствующих специальностей.
Разработка приложений в среде Linux. Второе издание - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
$ cat hw
cat: hw: No such file or directory
cat: hw: Файл или каталог не существует
$ ./hwwrite
$ cat hw
Добро пожаловать!
$
Для изменения этой программы, чтобы она читала файл, нужно просто изменить open()
, как показано ниже, и заменить write()
статической строки на read()
в буфер.
open("hw", O_RDONLY);
Файлы Unix можно разделить на две категории: просматриваемые (seekable) и непросматриваемые (nonseekable) [43] Хотя такое разделение почти ясно, сокеты TCP поддерживают "внеполосные" данные, что несколько усложняет ситуацию. Такие данные выходят за пределы тем, рассматриваемых в этой книге. Их полное описание можно найти в [33].
. Непросматриваемые файлы представляют собой каналы, работающие в режиме "первый вошел — первый вышел" (FIFO), которые не поддерживают произвольное чтение или запись, их данные не могут быть перечитаны или перезаписаны. Просматриваемые файлы позволяют читать и писать в произвольное место файла. Каналы и сокеты являются не просматриваемыми файлами; блоковые устройства и обычные файлы являются просматриваемыми.
Поскольку FIFO — это непросматриваемые файлы, то, очевидно, что read()
читает их с начала, a write()
пишет в конец. С другой стороны, просматриваемые файлы не имеют очевидной точки для этих операций. Вместо этого здесь вводится понятие "текущего" положения, которое перемещается вперед после операции. Когда просматриваемый файл изначально открывается, текущее положение устанавливается в его начало, со смещением 0. Если затем из него читается 10 байт, то текущее положение перемещается в точку со смещением 10 от начала, а запись 5 байт переписывает данные, начиная с одиннадцатого байта в файле (то есть, со смещения 10, где расположена текущая позиция после чтения). После такой записи текущая позиция находится в позиции, смещенной на 15 относительно начала файла — сразу после перезаписанных данных.
Если текущая позиция совпадает с концом файла и процесс пытается читать их этого файла, то read()
возвращает 0 вместо ошибки. Если же данные записываются в конец файла, то он растет с тем, чтобы вместить дополнительные данные, и его текущая позиция устанавливается в конец файла. Каждый файловый дескриптор отслеживает независимую текущую позицию [44] Почти независимую; см. описание исключений из этого правила в дискуссии о dup() в конце этой главы.
(она не хранится в файловом inode), поэтому если файл открыт множество раз множеством процессов, или несколько раз одним и тем же процессом, то чтения и записи, выполняемые через один дескриптор, никак не влияют на позиции чтения и записи, выполненные через другой дескриптор. Конечно, множественные операции записи могут повредить файл другими способами, поэтому блокировка определенного рода в такой ситуации может понадобиться.
Файлы, открытые с флагом O_APPEND
ведут себя несколько иначе. Для таких файлов текущая позиция перемещается в конец файла перед тем, как ядро осуществит в него запись. После записи текущая позиция перемещается в конец записанных данных, как обычно. Для файлов, работающих в режиме только для добавления, это гарантирует, что текущая позиция файла всегда будет находиться в его конце немедленно после вызова write()
.
Приложения, которые хотят читать и писать данные с произвольного места файла, должны установить текущую позицию перед выполнением операции чтения или записи данных, используя lseek()
.
#include
int lseek(int fd, off_t offset, int whence);
Текущая позиция для файла fd
перемещается на offset
байт относительно whence
, где whence принимает одно из следующих значений:
SEEK_SET
[45] Поскольку в большинстве систем SEEK_SET определена как 0, часто можно увидеть использование lseek(fd, offset, 0) вместо lseek(fd, offset, SEEK_SET) . Это делает код непереносимым (или плохо читабельным), чем 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
.
Хотя текущая позиция не разделяется другими процессами, которые одновременно имеют доступ к файлу [46] Все же не всегда. Если процессы разделяют файловые дескрипторы (имеются в виду дескрипторы, полученные от одного вызова open() ),эти процессы разделяют одни и те же файловые структуры и одно и тоже текущее положение. Наиболее часто такое случается после вызова fork() ,как обсуждается в конце этой главы. Другая ситуация, когда такое может случиться — это если файловый дескриптор передается другому процессу через доменный сокет Unix, описанный в главе 17.
, это не значит, что множество процессов могут безопасно осуществлять совместную запись в файл. Пусть имеется следующая последовательность.
Процесс 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()
. Файлы с "дырками" часто используют для хранения редко расположенных в них данных, таких как файлы, представляющие хеш-таблицы.
Интервал:
Закладка: