os161 родительский и дочерний поток pid - PullRequest
1 голос
/ 11 ноября 2011

Кто-нибудь знаком с os / 161 и может ответить на несколько вопросов для меня?

Как именно работает дочерний pid, родительский pid.

Я знаю, что когда вы вызываете thread_fork(), вы создаете другую базу потоков на текущем потоке, новый поток должен иметь уникальный идентификатор для себя и другую таблицу дескрипторов файлов. В то время как sys_fork создает дочерний элемент из curthread, дочерний элемент совпадает с родительским, кроме pid. Но я не совсем понимаю, как работает pid и родительский pid.

Это моя интерпретация таблицы процессов. Для всей системы существует только одна таблица процессов. На данный момент у меня есть parent_pid и my_pid для каждого потока.
-У родительского потока может быть несколько дочерних элементов (продолжая вызывать sys_fork).
-Детский ребенок может иметь только одного родителя.
-При каждом вызове sys_fork создается дочерний элемент, а parent_pid для этого дочернего элемента устанавливается в pid потока, создавшего этот дочерний элемент.
-pid of 1 - для темы загрузки / меню.

Я даже на правильном пути в понимании того, как работает таблица процессов?

Последний вопрос: Для sys_waitpid(): только родитель может использовать waitpid? и они могут только ждать своих детей? Может ли ребенок использовать waitpid на родителе (или это приведет к тупику)?

Я искал в Google, но нахожу так много противоречий, что до сих пор не могу найти четкий ответ на свои вопросы.

1 Ответ

3 голосов
/ 11 ноября 2011

Я ничего не знаю об OS / 161 - но ваше описание очень похоже на стандартную систему POSIX. Итак, вот как ваши вопросы работают с POSIX и, надеюсь, они будут иметь смысл и для OS / 161.

Только родители когда-либо звонят waitpid(). Приложения разработаны вокруг этого. Спецификация POSIX waitpid() требует возврата ошибки с errno, установленным в ECHILD, если pid не является потомком вызывающего процесса.

Дети могут определить, умер ли их родитель, проверяя свои parent pid: getppid(3). Если это 1, то их родитель умер, и их родитель был установлен на init. (init готов пожать всех детей-сирот, когда они умрут, поэтому состояние процесса не затягивается и не заполняет таблицу системных процессов процессами-зомби.) (Современные системы не имеют "процесса" table "больше, но pids должен быть переработан, и некоторая информация управления процессом должна оставаться в ядре до тех пор, пока не будет вызван какой-то wait(), чтобы пожинать процесс. Эта память слишком важна, чтобы оставлять ее без дела надолго.)

...