So i'm putting some time and thoughts into all this.. and there are a couple of things that are going on in my mind.. Sorry if it isn't easy to read, but i don't have enough time to write it down more coherently..
First of all, i'm only familiar with the x86 architecture, and the only reasonably way i can think of to do multi-tasking on x86 is using the timer interrupt... I'm going to assume it works like this on all platforms, because i, perhaps due to lack of imagination, can't imagine another way of doing this (efficiently). Right, so the way i see it, the timer interrupt gets called with a certain frequency and in the code that the interrupt executes the scheduler is called.. The scheduler stores the current thread register information (and will also have to store some stack/memory related information), determines which thread runs next and loads it's stored register and stack/memory information, and the interrupt returns. Maybe the storing of register information etc. be done right at the start of the interrupt, but then how can we abstract the scheduler efficiently? Unless the "schedule" function in the scheduler IS the interrupt routine i suppose... Anyway... Now it seems to me that checking how long the current thread has run, to determine if the next thread needs to run, needs to be done in the scheduler.. Unless the timer frequency is set pretty low? But that might be scheduler specific i suppose.. no idea how fast or possible it is to continually change the frequency of the timer interrupt either (doesn't sound like a very good idea), but constantly polling if we actually need to switch threads sounds like a rather bad idea as well.. Someone with more experience with this; any suggestions? Also, i haven't really tought about process creation in detail yet (where does the code come from, where do i store processes?) nor shutdown. In the simple test fifoscheduler i'm writing i'm handling shutdown like this: Currently if there suddenly are, without warning, no more threads in the queue, a kernel error is generated (but it's not really hooked up to anything yet) If, however, the last process is removed a kernel event should be generated, but right now it just calls a halt/shutdown function (which is also not implemented yet) Unfortunatly i need some stuff that the AOT does not supply, like class support, but also ADCStub for classes, and right now the fifoscheduler uses the generics list class.. but that could be done differently. Being able to tell the AOT to inline certain functions would also be nice, especially for really simple functions like "disableinterrupts"/"enableinterrupts" (can anyone think of a more platform independent name for these?) Finally, I also haven't put any toughts into memory handling and security. Well, other than that memory management should also be 'plugable', just like the scheduler, because some applications will need different memory management policies (server applications vs desktop applications vs handheld applications) Hell, maybe some drivers could be allowed to use non-garbage-collected memory management... but that's a whole discussion on itself.. So.. sorry again for being rather chaotic in my writing. But take a look at the code in "\sandbox\logicalerror\KernelScheduling" and if you have some ideas (or code) to share, or to tell me that i'm completely on the wrong track; please tell me! ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
