Clan x86
Technical (Development, Security, etc.) => General Programming => Operating System Development => Topic started by: Warrior on October 19, 2005, 09:47:30 pm
-
I decided to implement Virtual Consoles (up to 4, not counting the "root" or "debug" console.)
Now my problem is, I want to be able to run more than one process at a time but eventually I would run out of VCs (after 4 tasks which need console I/O are spawned) and I don't want two processes running on the same VC.
What I have done, is something like "Task Queueing" where tasks wait in line for a spot in any virtual console.
Now the way the tasks are selected for each Queue is.
TaskA in line for VC1TaskB in line for VC2TaskC in line for VC3TaskD in line for VC4
Right now, all VCs are filled with executing processes but say another task is spawned now my function would loop through every VC, check how many people are in line, and find the shortest one. Example:
Looping..found best (waittime: 1) in VC1Looping..wait time the same in VC2, skipLooping..wait time the same in VC3, skipLooping..wait time the same in VC4, skip
It would then place you in line for VC1
Two things I was thinking of doing but am unsure about:
1. Allow higher prioritized tasks a "cut" in line.
2. Allow people waiting in line longer to go to less wait time places if for example:
2 people in line for VC21 person in line for VC33 people in line for VC4
The oldest person who isn't the VERY next -OR- the VERY last would get a chance to move lines to a different VC with the least people (VC3)
Reason for not allowing it to be the very next:
It's bound to be next, give someone else a chance! :p
Reason for not allowing it to be the very last:
It just arrived, wait a lil. Although the odds of it not already being in best placement are slim.
Condition for being able to switch lines:
Lines must have less people than you (obviously)
Comments and suggestions are welcome.
[Taken from a post on OSDev boards, looking for a second opinion]
-
Seriously dude, modern processors have support for hardware threading. Why don't you just implement your OS with multithreading? It looks like you're not even considering it.
-
I would type up an explination but I gtg, will explain tomorrow.
-
I would type up an explination but I gtg, will explain tomorrow.
It's okay, you don't have to explain. It's all summed up in the title of this thread (http://www.x86labs.org/forum/index.php/topic,3342.0.html).
-
Hahahahah
-
I can already spawn threads which store thier information in the TSS and use software based task switching (for portability between architectures, mostly). The way I vision it, a task is handled as a kernel thread if it supplies the special flags in the CreateTask() function.
So far, two tasks are spawned on the kernel init, this is Zombie Slayer and VC Manager
The only time a task switch occurs is when an interrupt fires in IRQ0 (PIT Timer), who's interval I have set to 100Hz.
My IRQHandler then forwards it to my scheduling function which makes all the necessary switches (context switch if necessary, stores old EIP, loads new one, etc..) Then does an explicit CALL or JMP to the new task code. Which is either the last instruction performed or the first instruction of the new task.
My zombie slayer handles tasks which have not been destroyed yet. The way Optimix does it, it doesn't destroy tasks right on the dot, it sets thier status as STATUS_ZOMBIE and STATE_FROZEN which removes them from the list of running tasks and makes them a zombie task. The slayer searches for Zombie Tasks and kills them by removing them once and for all and free()'ing up all thier (virtual and physical) memory.
The VC manager will hopefully do what I suggested above and in making it a thread I effectively stop it from blocking anything which is useful to the kernel (like the actual kernel :P).