6.7 linux process

real_parent  points to the process descriptor of the process that created P or to the descriptor of process 1 (init) if the parent process no longer exisit.(therefore when a user starts a background
process and exits the shell, the back ground process becomes the child of init)

parent points to the current parent of P(this is the process that must be signaled when the child process terminate),its value usually coincides with that of real_parent.
it may occasionlly differ, such as when another process issues a ptrace() system call requesting that it be allowed to monitor P.

children  the head of  the list containing all children created by P

sibling the pointer  to the next and previous elements in the list of the sibling processes, those that have the same parent as P

there exist other relationships among processes 

a process can be a leader of a process group or of a login session, it can be a leader of a thread group, and it can also trace the execution of other processes 

group_leader  process descriptor pointer of the group leader of P

signal->pgrp PID of the group leader of P

tgid  PID of the thread group leader of P

signal->session PID of the login session leader of P

ptrace_children  the head of a list containing all children of P being traced by a debugger 

ptrace_list the pointers of the next and previous elements in the real parent's list of traced processes(used when P is being traced )

The pidhash table and chained list

the kernel must be able to derive process descriptor pointer corresponding to a PID this occurs, for instance, in servicing the kill() system call

when process P1 wished to send a signal to another process, P2, ti invokes the kill() system call specifying the PID of P2 as the parameter

the kernel derives the process descriptor pointer from the PID and thenextracts the pointer to the data structure that records the pending signals from P2's process descriptor.

scanning the process list sequentially and checking the pid fields of the process descriptor is feasible but rather inefficient

four hash tables havebeen introduced

Hash table type    Field name   description

PIDTYPE_PID      pid                   PID of the process

PIDTYPE_TGID   tgid                  PID of thread group leader process

PIDTYPE_PGID  pgrp                 PID of the group leader process

PIDTYPE_SID     session           PID of the session leader process

the four hash tables are dynamically allocated during the kernel initialization phase, and their addresses are stored in the pid_hash array.

the size of a single hash table depends on the amount of available RAM

each hash table is stored in four page frames and included 2048 entries

The PID is transformed into a table index using the pid_hashfn macro, which expands to #define pid_hashfn() hash_long((unsigned long) x, pidhash_shift)

the pidhash_shitft variable stores the length in bits of a table index(11, in our example)

the hash_long () function is used by many hash functions on a 32-bit architecture it is essentially equivalent to 

unsigned long hash_long(unsigned long val , unsigned int bits)

{

unsigned long hash=val*0x9e370001UL;

return hash>>(32-bits);

}

because in our example pidhash_shift is equal to 11, pid_hashfn yield values ranging between 0 and 2^11 - 1=2047

this hash function is based on a multiplication of the index by as suitable large number,so that result overflows and the value remaining in the 32-bit variable can be considered as the result of a modulus operation.

a hash function does not always ensure a one to one correspondence between PIDs and table indexes.

Two different PIDs that hash into the same table index are said to be colliding.

Linux uses chaining to handle colliding PIDs.

each table entry is the head of a doubly linked list of colliding process descriptor.