>It is unlikely that this is the case, since PIDs run the range from 1
>to 32767, or so. Most likely, the PID is an entry in the process
>structure in the kernel. If you really want to track it down, look
>through the code that implements fork() (kernel/fork.c), as that is
>the only way that new processes are created.
What does PID running in a specific range have to do with it? SCO has PIDs that run in a specific range *and* the size of the process table grows dynamically *and* the PID is the slot number in the process table. Also,
isn't the task[]array the "process structure in the kernel." Looking through the kernel source, I only see references to tasks and not to processes. So, what structure is the "process structure"?
If not an offset in an array, but rather some arbitrary number, then the kernel (or whatever) has to search an average of half the table *each time* before it finds the right process when:
- sending a kill to a particular processes
- doing a ps -p <PID>
- passing the exit value of the process back to the parent
- Any time you need information about a speficic PID.
> I am unclear about the differences between bdflush and update. I
> understand that bdflush is "part" of update and per the man-page is
> "called by a user without superuser priveledges." Do I take this to
> mean that processes not owned by root call bdflush and the others
> call update?
>I don't understand it fully myself, but it is all part of a system
>process that you must have (in order to get changed buffers flushed
>back to disk regularly) but otherwise you don't have to worry about
>it.
Sorry, Dale, the question was not whether I should worry about them. I know about buffer flushing and why it is done. SCO just has bdflush, not update. What is so different about the the way Linux handle buffer flushing that requires two daemons?
> Some one said that "Clearing the process table slot of an exiting
> process is not the responsability of init, but of the parent. If
> all the forefathers have died, init will take over." To me that
> says that if I write a simple "Hello, World!" program, it will have
> the code to clean up the process table. (maybe in a dynamically
> linked library) To me that is system work and the parent process
> should do it.
>The process table slot is cleared when the "parent" process does a
>wait() call which gets the information regarding the exiting of the
>process. If a process's parent exists, all of its child processes
>automagically become children of process 1, which is init. Since init
>almost always is doing a wait() (look at sys_wait4() in
>kernel/exit.c), this happens promptly after the process exits.
Here again, that wasn't the question. I know when the process table entry is cleared, I know what is kept in the the process table entry after the process dies, and I know what happens when there is no parent waiting on the child. So, to put the question as clear as I can:
Is it true that the parent process is responsible for clearing the process table of child processes or is this done by init or some other process, kernel function, whatever?
>When I do a ps, I see that more than open process is waiting on
>read_chan. No problem. What annoys me is that when I look at the
>numeric output for the WCHAN, they are all the same one. Other
>UNIXes will have a different WCHAN for each tty that is being
> waited upon. Therefore, the number here is different.
>That is a statement, not a question. There is probably no reason for
>WCHAN values to be handled similarly in different Unixes.
Wait channels are essentially the address of the routine that the process was at when it went to sleep. The values *are* handled the same in different Unixes as all UNIX (that I know of) use wait channels and they serve the same function. The question is "why would the WCHAN be the same for all processes?"
In SCO, the virtual memory of each process between 3Gb-4Gb is for portions of the kernel that the process is using. So, when I am using a device, I have a particular driver loaded that ends up in the 3-4Gb range. Although two (or more) processes are waiting on the same event (i.e. input from the keyboard) and the WCHAN maps to the same function, the numeric WCHAN value is different. In Linux, both the numeric value and the address mapping is the same.
This brings up the question of how kernel address space is mapped into the user's process space.
Regards,
jimmo
>Dale
>--
>Dale R. Worley Ariadne Internet Services
>Voice: +1 617-899-7949 Fax: +1 617-899-7946 E-mail: worley@ariadne.com
>"Internet-based electronic commerce solutions to real business problems."