Поведение виртуального таймера Linux в потоках клонов - PullRequest
1 голос
/ 27 января 2010

Я сделал следующее:

  1. Создайте виртуальный таймер, который будет запускаться несколько раз.
  2. Установить обработчик сигнала для SIGVTALRM
  3. вызов клона syscall
  4. Установите sched_affinity так, чтобы клонированный поток работал на другом процессоре

Будет ли клонированный поток также прослушивать SIGVTALRM? Так будут ли оба потока вызывать обработчик сигнала при запуске SIGVTALRM? Кроме того, после создания нового потока можно ли изменить его обработчик сигналов для SIGVTALRM на другую функцию, не затрагивая обработчик сигналов основных потоков?

Полагаю, это зависит от флагов, переданных clone (). В основном я использую CLONE_SIGHAND и SIGCHLD. Это зависит и от других флагов?

1 Ответ

1 голос
/ 28 января 2010

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

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

Что произойдет, если при попытке изменить обработчик сигнала у дочернего элемента зависит флаг CLONE_SIGHAND. Если он не установлен, тогда ребенок может с радостью вызвать sigaction, чтобы изменить обработчик сигнала, не затрагивая родителя; но если установлено CLONE_SIGHAND, то когда дочерний объект вызывает sigaction, обработчик сигнала изменяется для всего процесса. Также обратите внимание, что если вы укажете CLONE_THREAD, вы также должны указать CLONE_SIGHAND.

Однако ребенок может использовать sigprocmask для маскировки сигнала SIGVTALRM, не затрагивая родителя.

...