Иерархия процессов (зачем?)

[fatboy]

Читал одну книжульку по ОС и для меня осталось загадкой почему в дескрипторе процесса хранятся указатели на дескрипторы родителя и потомков. С указателями на следующий и предыдущий процес все ясно а с родственниками... Т.е. должна быть какая-то последовательность процессов хотя бы для того чтобы ниодин не "потерялся", но зачем хранить иерархию?

[Voice]

Например, что бы при завершении процесса послать родителю сигнал.

[Славик]

Хм, если нет в памяти дерева процессов, и умирает один из родителей, как уложить спатки оставшихся без присмотра деток?

[fatboy]

Хм, если нет в памяти дерева процессов, и умирает один из родителей, как уложить спатки оставшихся без присмотра деток?

А зачем? Вот, например, форкнул один процесс какой-то демон, и умер, не прибивать же демона... Есть такой вариант: при создании процесса ему выделяется доступ к отрытым файловым дескрипторам родителя, таким образом, чтобы знать у кого брать эти ресурсы менеджеру процессов нужно знать PID родителя. Но это на этапе создания... И вообще родитель и потомок делят доступ к открытым файлам. Скорее всего, при открытии новых файлов родителем или потомком, менеджер процессов помещает их дескрипторы в адресное пространство как родителя так и потомка. Но об этом в книге ничего нет, и это - просто моя догадка. Там написано только про доступ к открытым файлам родителя, созданным к моменту порождения потомка.
Знает-ли кто-либо как это есть на самом деле?

Т.е., Славик, Ваш вариан тоже разумен, но с точки зрения иерархической структуры. Получается, что у каждого процесса есть указатели на дескрипторы родителя потомков чтобы в случае завершения текущего процесса менеджер процессов знал какие процессы кому передать (потомков передать пра-родителю), но это лишь для того чтобы поддержать иерархию. А зачем? Почему для управления процессами не достаточно указателей на дескрипторы предыдущего и следуещего процессов( struct task_struct *next_task, *prev_task для Linux до версии 2.6 )?

[Rootlexx]

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

При обычном fork() дочерний процесс делит адресное пространство родительского процесса в режиме копия-при-записи. Никакие PID и PPID для этого не нужны, вызов осуществляется на более низком уровне.

Скорее всего, при открытии новых файлов родителем или потомком, менеджер процессов помещает их дескрипторы в адресное пространство как родителя так и потомка.

Нет. Файлы, открытые после fork(), обособлены, их дескрипторы ни с кем не разделяются.

потомков передать пра-родителю

Если родительский процесс завершается, то для всех его дочерних родительским становится init.

Почему для управления процессами не достаточно указателей на дескрипторы предыдущего и следуещего процессов

Родительский процесс ведь не просто отдельный процесс. Он получает данные о выполнении своих потомков. Поэтому ему необходимо знать их PID'ы, чтобы, к примеру, поймать код их завершения (смотрите waitpid()).

Вот, например, форкнул один процесс какой-то демон, и умер, не прибивать же демона...

Если это действительно демон, то он при запуске сделает себя лидером сеанса и откроет свои собственные стандартные потоки ввода-вывода. Но если это, скажем, оболочка bash, в которой запущен tar, то после завершения работы оболочки все дочерние процессы принудительно отключаются от терминала, что делает ввод-вывод на стандартные потоки невозможным. Группа процессов, в которую входит tar, станет висячей, и всем членам группы будет послан сигнал SIGHUP. А для этого нужно знать всех потомков оболочки.
Разумеется, после стандартного fork() дочерний процесс не завершится вместе с родительским. Но есть ситуации, когда это необходимо,

[fatboy]

Значит больше половины прочитанного я понял неправильно Придется перечитывать. Rootlexx, спасибо за разъяснения. Спасибо всем ответившим.