QNX/UNIX: Анатомия параллелизма

  sigset_t sig;
  sigemptyset(&sig);
  //определение #define SIGUSR1 16
  sigaddset(&sig, SIGUSR1);
  sigprocmask(SIG_BLOCK, &sig, NULL);
  struct sigaction act;
  act.sa_mask = sig;
  act.sa_sigaction = handler;
  act.sa_flags = SA_SIGINFO;
  if (sigaction(SIGUSR1, &act, NULL) < 0)
  perror("set signal handler"), exit(EXIT_FAILURE);
// создать новый (дочерний) процесс
  const char* prg = "./p1ch", *sdelay = "3";
  pid_t pid =
  ((argc > 1 ) && (atoi(argv[1]) >= sched_get_priority_min(SCHED_RR)) &&
  (atoi(argv[1]) <= sched_get_priority_max(SCHED_RR))) ?
  spawnl(P_NOWAIT, prg, prg, sdelay, argv[1], NULL) :
  spawnl(P_NOWAIT, prg, prg, sdelay, NULL);
  if (pid == -1)
  perror("spawn child process"), exit(EXIT_FAILURE);
  // размаскировать и ожидать сигнала.
  sigprocmask(SIG_UNBLOCK, &sig, NULL);
  while (true) {
  if (sleep(3) != 0) continue;
  cout << "parent main loop: priority = " << getprio(0) << endl;
  }
 }

Дочернее приложение ( файл p1ch.cc), которое и будет запускать показанный выше родительский процесс:

 #include <stdio.h>
 #include <iostream.h>
 #include <sched.h>
 #include <unistd.h>
 #include <signal.h>

 int main(int argc, char *argv[]) {
  int val, del = 5;
  if ((argc > 1) &&
  (sscanf(argv[1], "%i", &val) == 1) && (val > 0)) del = val;
  if ((argc > 2) &&
  (sscanf(argv[2], "%i", &val) == 1 ) && (val > 0) &&
  (val <= sched_get_priority_max(SCHED_RR)))
  if (setprio(0, val) == -1) perror("set priority");
  // периодически уведомлять родителя SIGUSR1, используя
  // его как сигнал реального времени (с очередью):
  while(true) {
  sleep(del);
  union sigval val;
  val.sival_int = getprio(0);
  // #define SIGUSR1 16
  sigqueue(getppid, SIGUSR1, val);
  }
 }

Примечание

Для многих сигналов действием на их получение, предопределенным по умолчанию, является завершение процесса. (Реже встречается действие по умолчанию — игнорировать полученный сигнал при отсутствии явно установленной для него функции обработчика.) Достаточно странно, что завершение процесса предусмотрено как реакция по умолчанию на получение «пользовательских» сигналов SIGUSR1 и SIGUSR2. Если показанное выше приложение в процессе отладки запустить вызовом из командной строки (из командного интерпретатора или, например, файлового менеджера mqc), то результатом (на первый взгляд не столь ожидаемым) станет завершение интерпретатора командной строки (родительского процесса) и, как следствие, самого тестируемого приложения.

Вот как выглядит начальный участок совместной работы двух процессов:

 # p1 15
 parent main loop: priority = 10
 SIG = 16: old priority = 10, new priority = 15
 SIG = 16: old priority = 10, new priority = 15
 parent main loop: priority = 10
 SIG = 16: old priority = 10, new priority = 15
 parent main loop: priority = 10
 SIG = 16: old priority = 10, new priority = 15
 parent main loop priority = 10
 SIG = 16: old priority = 10, new priority = 15
 parent main loop: priority = 10
 SIG = 16: old priority = 10, new priority = 15
 parent main loop: priority = 10

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

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

Завершение процесса

С завершением процесса дело обстоит достаточно просто, по крайней мере, в сравнении с тем, что происходит при завершении потока, как это и будет показано очень скоро. Процесс завершается, если программа выполняет вызов exit или выполнение просто доходит до точки завершения функции main, будь то с явным указанием оператора return или без оного. Это естественный, внутренний (из программного кода самого процесса) путь завершения.

Другой путь — посылка процессу извне (из другого процесса) сигнала, реакцией на который (предопределенной или установленной) является завершение процесса (подробнее о сигналах и реакциях см. ниже). В противовес естественному завершению такое принудительное завершение извне в [12] (по крайней мере, в отношении потоков) названо отменой, и именно этим термином мы будем пользоваться далее, чтобы отчетливо отмечать, о каком варианте завершения идет речь. (Такая же терминология будет использоваться нами и относительно завершения потока.)