OSDev.org

Hi.. I have made a scheduler and It works quite well.. Now I have a problem though. Killing processes.

When a process returns from main() it is assumed it will kill itself. Well, the way my scheduler works it seems to be impossible without either having a memory leak from unfree'd stacks or writing into free'd memory.

My scheduler works by pushing the context info onto a esp0 stack or regular stack for kernel processes. Then a context switch silently changes the esp0 and regular stack so it pops the context info transparently.

How would a process kill itself however? If a system-call destroys the process. It then has to wait for the scheduler to kick in to switch processes. Well, where will the context information go? it will either overwrite another task or it will go into undetermined memory..

How have you handled having processes destroy themselves? cause I think I'm just missing something here.

You might try having a flag to say "Hey, scheduler, kill this process!" and when the scheduler gets to it, the scheduler cleans up the structures and frees the memory, then moves on to the next process. That way the scheduler will not have to even switch contexts for the process to finally kill itself. The kill-self syscall can simply mark the process as dead, then yield to the next process. Yeah, it'll take a whole go-around before the process is actually removed and cleaned up, but keeping track of everything should be easier...

You could make the flag an int or something and use it to mark sleeping or blocked threads too...

Ok, that sounds simple enough.. .I don't understand the whole blocked thread concept thing though. Like, if a process is waiting on disk access, then it gets blocked right and is skipped for scheduling until some condition is true. But how would the disk communicate to the scheduler that it needs to unblock that thread?

In the interrupt handler notify the scheduler the thread needs unblocked.

The terminology in my kernel is sleep()/wakeup(). A process goes to 'sleep()' waiting on an I/O request completing. (It gets moved from the run queue to the sleep queue). The disk controller raises an interrupt. The IRQ handler calls 'wakeup()' which moves the process back onto the run queue.

Simples! (people who watch UK TV may get that)

Firestryke31 wrote:You might try having a flag to say "Hey, scheduler, kill this process!" and when the scheduler gets to it, the scheduler cleans up the structures and frees the memory, then moves on to the next process. That way the scheduler will not have to even switch contexts for the process to finally kill itself. The kill-self syscall can simply mark the process as dead, then yield to the next process. Yeah, it'll take a whole go-around before the process is actually removed and cleaned up, but keeping track of everything should be easier...

You could make the flag an int or something and use it to mark sleeping or blocked threads too...

I wondered about this for a while too and ended up doing exactly what Firestryke is proposing . Basically what I do is have a linked list (Round Robin) of processes. The structure of a proces has a boolean (or an unsigned of 1 bit or whatever you desire) variable which is false all the time and gets set to true if the process needs to be destroyed ASAP. Then, as soon as the scheduler gets called again, it will parse the linked list, removing and killing every process that has the flag set. Also make sure that if you're using the Round Robin way of multitasking that you relink the processes that aren't destroyed (set their Next or Previous variables to their correct values again). Then the scheduler simply switches to another process.

I take the destroyed process completely out of the run list and add it to a destroyed task list. Then when the IDLE task gets some time it goes through the destroyed task list and frees their resources. That way there is no extra overhead in the scheduler for destruction of processes.

why is a round-robin method needed? I used a simple one-way approach(only have a next field with a first_process and current_process variables) and it works just fine and is much easier to maintain in my opinion.. Sure the scheduler has to see if next==NULL but at least you don't have to deal with making the list round when creating a new process..(and trying to make an attached thread list round-robin is even harder)

And I will consider that idea of using the idle thread to cleanup old tasks..

earlz wrote:why is a round-robin method needed? I used a simple one-way approach(only have a next field with a first_process and current_process variables) and it works just fine and is much easier to maintain in my opinion.. Sure the scheduler has to see if next==NULL but at least you don't have to deal with making the list round when creating a new process..(and trying to make an attached thread list round-robin is even harder)

And I will consider that idea of using the idle thread to cleanup old tasks..

Yes, I was merely stating it as an example. I'm using a simple 'FirstProcess' and Next singly linked list as well. The point is that you can just let the scheduler do things and give the processes in the linked list a parameter. Either way, you still have to relink the list if you remove one of the processes (unless it's the first process, which you shouldn't be able to kill anyway if it's the kernel process and if you did, the FirstProcess pointer would still have to be given another value).