Is anyone familiar with os/161 and can answer a few questions for me?
How exactly does child pid, parent pid works.
I know that when you call thread_fork() you are creating another thread base on the current thread, the new thread should have a unique id for himself and a different file descriptor table. While sys_fork create a child from curthread, the child is the same as the parent besides the pid. But I am confused in how pid and parent pid works.
This is my interpretation of the process table. There is only one process table for the whole system. For now I have parent_pid and my_pid for every thread.
-A parent thread can have multiple child, (by keep calling sys_fork).
-A child can only have one parent.
-Whenever sys_fork is called, a child is created and the parent_pid for this child is set to the pid of the thread who created this child.
-pid of 1 is for the boot/menu thread.
Am I even on the right track in understanding how process table works?
One last question:
For sys_waitpid(): Only parent can use waitpid? and they can only wait on their childs? Can a child use waitpid on a parent (or would this result in deadlock)?
I been searching around with Google, but I find so many contradictions, up till now I still can't find a clear answer to my questions.
I know nothing of OS/161 -- but your description sounds a lot like a standard POSIX system. So, here's how your questions work with POSIX and hopefully they'll make sense for OS/161 as well.
Only parents ever call waitpid(). Applications are designed around this. The POSIX specification of waitpid() requires returning an error with errno set to ECHILD if the pid is not a child of the calling process.
Children can determine if their parent has died by checking their own parent pid: getppid(3). If it is 1, then their parent has died and their parent has been set to init. (init is prepared to reap all orphaned children when they die, so the process state doesn't linger and fill the system process table with zombie processes.) (Modern systems don't have a "process table" any longer, but the pids must be recycled and some process control information must remain in the kernel until wait() of some sort has been called to reap the process. That memory is too important to leave idle for long.)