The pid, parent, child, and sibling fields tell us the relationship of this process to other processes. Obviously, pid is the process ID of the process itself, and parent is the process ID of the process that created this one. Where things get interesting is the child and sibling entries. Let's take an example of a process P that created processes A, B, and C. Process P is the parent of A, B and C, thus we'd expect that the parent field would contains the process ID for process P (in each of the three children processes). However, you'll notice that the child member is a scalar, and not an array as you may have been expecting. This means that P's children are listed as a child/sibling relationship, rather than an array of children. So, it may be the case that P's child member is the process ID for process A, and the other children, B and C are listed as siblings (in the sibling member) of each other. So, instead of:
Figure 1. A parent/child relationship.we'd see a relationship more like:
Figure 2. A parent/child/sibling relationship.It's the same, hierarchically speaking, except that we've avoided having to keep an array of children. Instead, we have each of the children point to a sibling, thus forming a list.
Additional process information provided is the process group (pgrp), session ID (sid), and the usual extended user and group information (uid, gid, euid, egid, suid, and sgid).
The process's base priority is provided in the priority member. Note that, practically speaking, a process doesn't really have a priority — since threads are the actual schedulable entities, they will be the ones that “actually” have a priority. The priority given here is the default priority that's assigned to the process's first thread when the process started. New threads that are started can inherit the priority of the creating thread, have a different priority set via the POSIX thread attributes structure, or can change their priority later.
Finally, the number of threads (num_threads) is provided.