OSDev.org

On how rights process can be killed in your OS ?

I was first thinking about such way:
- root process can kill any process
- user process can kill only himself or his childrens (processess that he create). It also means that when he is killing himself all his childrens are killed and childrens of that childrens etc.

But such thing is a little bit complicated because of its recursive construction so now I'm thonking about something like this:

- root process can kill anybody
- user process can kill any process of that user, and himself (but before killing himself he should send kill signal to his childrens).

On what rights process can be killed in windows/linux/other Os?
What do you think about such resolutions ?

It is in about that order with many OSes.

It would probably be a good idea to kill all children of a particular process if that process is being killed itself. This a standard thing to do.

Yes, but should kernel kill childrens when process is finishing (automatic killing by kernel) or should kernel just support killing of one process and it needs himself to send kill signal to his childrens (killing by parent option)?

Depends on the situation. Killing a process in the middle of a write operation would be bad. Sending a termination signal to a process that will not respond is also bad.

I suggest mixing the 2. Send termination signals to all the involved processes and set a time-out of X amount of seconds. After the time-out, if any processes are still active, forcefully kill them.

1. Be graceful.

2. If that doesn't work, kill it.

I know that I should give process some time to finish the job. This are basics so I don't know why you are talking about that ;/.

I am just asking what functionality space should have my kernel (microkernel). If he will be killing childrens of process too by himself I need to write some extra structures inside process-management part of it. If kernel will just kill some pointed process then it's internal structures will be easier but more responsibility lies on father (to send term , then kill signal to his childrens). This is what I'm talking about.

Then you seem to be making a comment and not asking a question.

If I'm not sure I make sure that the basic are known right. Saved already a lot of time asking about those first.

You seem to understand the basics. I think you might be wondering about the actual implementation (code).

I usually don't recommend this, but you can look at the Linux kernel source for inspiration/guidance in this matter.

mrkaktus wrote:I know that I should give process some time to finish the job. This are basics so I don't know why you are talking about that ;/.

Rather then giving a process "some time" to finish up, why not just have separate calls, one for signalling a process to terminate (catchable and ignorable), and another to terminate a process involutarily (immediate and non-catchable). Defining some fixed amount of time that a process has to finish up is arbitrary and may not be appropriate for every process, plus it requires that the kernel babysit the process for a while.

mrkaktus wrote:I am just asking what functionality space should have my kernel (microkernel). If he will be killing childrens of process too by himself I need to write some extra structures inside process-management part of it. If kernel will just kill some pointed process then it's internal structures will be easier but more responsibility lies on father (to send term , then kill signal to his childrens). This is what I'm talking about.

I don't recommend having the kernel kill all the children of a process automagically. Instead, you could use process groups to deliver a signal to related processes. There are a lot of cases in which you don't want the children of a process to die.

Thanks for suggestions rexlunae .