Операционная система UNIX

  naddr, nbrk, nbrk — obrk);
  /* "Освободим" выделенную память и проверим, что произошло
  на самом деле */
  free(naddr);
  printf("free(0x%x)\n", naddr);
  obrk = sbrk(0);
  printf("Новый брейк-адрес= 0x%x (увеличение на %d байтов)\n",
  obrk, obrk — nbrk);
 }

Откомпилируем и запустим программу:

 $ a.out
 Текущий брейк-адрес= 0x20ac0
 malloc(64)
Новый адрес области malloc = 0x20ac8, брейк-адрес = 0x22ac0
 (увеличение на 8192 байтов)
 free(0x20ac8)
 Новый брейк-адрес = 0x22ac0 (увеличение на 0 байтов)
 $

Как видно из вывода программы, несмотря на освобождение памяти функцией free(3C), значение брейк-адреса не изменилось. Также можно заметить, что функция malloc(3C) выделяет больше памяти, чем требуется. Дополнительная память выделяется для необходимого выравнивания и для хранения внутренних данных malloc(3C), таких как размер области, указатель на следующую область и т.п.

Создание и управление процессами

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

Новый процесс порождается с помощью системного вызова fork(2):

 #include <sys/types.h>
 #include <unistd.h>

 pid_t fork(void);

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

 идентификаторы пользователя и группы,

 переменные окружения,

 диспозицию сигналов и их обработчики,

 ограничения, накладываемые на процесс,

 текущий и корневой каталог,

 маску создания файлов,

 все файловые дескрипторы, включая файловые указатели,

 управляющий терминал.

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

Легче перечислить немногочисленные различия между этими процессами, а именно:

 дочернему процессу присваивается уникальный идентификатор PID.

 идентификаторы родительского процесса PPID у этих процессов различны,

 дочерний процесс свободен от сигналов, ожидающих доставки,

 значение, возвращаемое системным вызовом fork(2) различно для родителя и потомка.

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

В возвращаемом fork(2) значении заложен большой смысл, поскольку оно позволяет определить, кто является родителем, а кто — потомком, и соответственно разделить функциональность. Поясним это на примере:

 main {
  int pid;
  pid = fork;
  if (pid == -1) {
  perror("fork");
  exit(1);
  }
  if (pid == 0) {
  /* Эта часть кода выполняется дочерним процессом */
  printf("Потомок\n");
  } else {
  /* Эта часть кода выполняется родительским процессом */
  printf("Родитель\n");
  }
 }

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

UNIX предлагает системный вызов, предназначенный исключительно для запуска программ, т.е. загрузки другого исполняемого файла. Это системный вызов exec(2), представленный на программном уровне несколькими модификациями:

 #include <unistd.h>

 int execl(const char *path, const char *arg0, ... ,
  const char *argn, char * /* NULL */);
 int execv(const char* path, char* const argv[]);
 int execle(const char *path, char *const arg0[], ... ,
  const char *argn, char* /* NULL */, char *const envp[]);
 int execve(const char* path, char const argv[],
  char *const envp[]);
 int execlp(const char *file, const char *arg0, ... ,
  const char* argn, char * /* NULL */);
 int execvp(const char *file, char *const argv[]);

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

Рис. 2.12. Семейство функций exec(2)

В отличие от вызова fork(2), новая программа наследует меньше атрибутов. В частности, наследуются:

 идентификаторы процесса PID и PPID,

 идентификаторы пользователя и группы,

 эффективные идентификаторы пользователя и группы (в случае, если для исполняемого файла не установлен флаг SUID или SGID),

 ограничения, накладываемые на процесс,