Reallocating queue space after process exits

[Rival]

Round-robin scheduling algorithm looked pretty straight forward to me. You maintain a queue of processes and execute them in round-robin fashion in time-slot basis. For this purpose, you also maintain a structure to hold process contexts.
But here's where my vision ended: You add a process to the queue. And when the time comes, dispatcher executes this processes for whatever time slot is being defined. Then another process kicks in and it goes round and round. Now, the question is what happens when the process executes its last instruction? There got to be someway to unallocate it's existence from the queue.

One way I can think of to handle this situation is to insert a wrapper around the process, which is in fact what is called an executable. This way, the wrapper can handler whatever the runtime requirements are and just before the process terminates, call the scheduler to free the slot that process is being allocated. However, this doesn't work for threads. So what could be the possible technique to alert the scheduler which works for both threads and processes.

Either I'm too stupid to miss something obvious or, just lazy to go into details. Either way, bear with me.

@Mods: Not sure if this is the right place to go so feel free to move this post around!

[iansjack]

The "exit" system call ought to handle this sort of thing.

[embryo2]

what happens when the process executes its last instruction? There got to be someway to unallocate it's existence from the queue.

If your OS is going to be safe it should implement a mechanism to watch a thread or a process. Usually there is a main procedure address and standard return instructions at the end of the procedure, so you can call the procedure and expect it to return to the next instruction after the actual call. Here you can do some house keeping. In case the procedure has not defined a correct return instruction sequence you should watch for a few interrupts like general protection or unknown opcode. Also you should employ the hardware protection available for your platform. If there's no hardware protection, then you'd better don't use unsafe code under your OS.

But most safe variant is not to use unsafe languages and to run a process/thread under a virtual machine.

[Rival]

The "exit" system call ought to handle this sort of thing.

That is probably the wrapper I'm talking about.

Anyway, a process is scheduled by OS kernel. It is the only one which knows the process' existence, other than the process itself. To be able to handle incoming signals (SIGTERM, SIGKILL) it needs to keep track of all running (and waiting) processes. I guess this is what embryo2 is referring to. But again, when a system call is raised, the operating system has no way to tell which process generated a system call right? It only knows how to respond, not whom to respond. So, if I'm correct exit() does not include sufficient information to notify the operating system about that specific process. So how does this all work?

Thank you for quick replies.

[edit] Okay, think I got it. To determine which process initiated the exit() system call, the operating system checks the queue for currently running process. This process should be the one that called the exit() because no other process is currently active. Sounds too generic though. [/edit]

[Rival]

But most safe variant is not to use unsafe languages and to run a process/thread under a virtual machine.

At this stage, a virtual machine, I suppose, is overkill. I'm trying to implement something more simpler, in fact, much simpler.

[iansjack]

Anyway, a process is scheduled by OS kernel. It is the only one which knows the process' existence, other than the process itself. To be able to handle incoming signals (SIGTERM, SIGKILL) it needs to keep track of all running (and waiting) processes. I guess this is what embryo2 is referring to. But again, when a system call is raised, the operating system has no way to tell which process generated a system call right? It only knows how to respond, not whom to respond. So, if I'm correct exit() does not include sufficient information to notify the operating system about that specific process. So how does this all work?

The kernel is not a separate process; it knows exactly which process generated a system call (the current one). Otherwise, how could any system call do useful work on behalf of a process?

I think the idea of thinking of the kernel as a separate entity is a mistake. It is a set of routines, that run with special priviliges, that any process can call.