On 9/11/07, Sander van Rossen <[EMAIL PROTECTED]> wrote:
>
> So i was looking a bit ahead, thinking about how we would implement a
> scheduler etc.
>
> The thing is, there are many different types of schedulers in the
> world.. and especially since no scheduler is perfect for anything,
> it's rather a type of black art, desiging schedulers, we might need to
> support different schedulers for different purposes (server, desktop,
> handheld etc.)
>
> Now we could simply have multiple kernels, and just like we have this
> build system for different architectures, we could add another layer
> of complexity to support multiple different schedulers..
>
> But this is definitely not scalable, nor easy to experiment with..
>
> So what if we have an IScheduler interface, and simply have multiple
> schedulers that inherit from this interface.
> Which scheduler is used could be configurable, and the right scheduler
> would be started at startup.
The idea is definitely plausible.
Basically the console, desktop or whatever process/threads (& drivers)
> would be added to the scheduler before it's started.. and then the
> scheduler would run those threads which in turn would load whatever
> else we need..
> So it shouldn't be too hard to implement an abstracted scheduler..
>
> Ofcourse the problem is is that AOT only has support for static methods..
> Would abstract classes be easier to implement?
Abstract classes and interfaces are almost the same thing. The AOT has to
generate a vtable so that we can lookup all these virtual calls at runtime.
Due to many different reasons, this is something that we will have to look
into sonner rather than later, I believe...
Also, i was thinking about how the .net platform has all these layers
> over the OS to simulate and handle things which are required but are
> somewhat incompatible with what the OS is doing..
> For instance, domains seem to be a bit like the 'process' equivalent
> of the .net platform..
> Not to mention, where does the runtime fit into all this? There are
> different runtimes for, for example, asp.net and winforms
> applications..
> Singularity takes the runtime and an application and then compiles it
> as a whole to create a single optimized binary..
> So how are we going to handle this all naming and compatibility wise?
Its defintiely a very big set of issues. The most I can say is, "one thing
at a time"...
Anyway, we really need some sort of design for the kernel, because
> even at this semi "hello world" level it's starting to become rather
> chaotic.
I have to agree. Especially since the trunk has been broken for over 2
months now, I believe its been. We definitely need some structure with how
we will proceed. I understand xfury and others are big on code first,
document later. I myself tend to agree. But we still need some basic,
documented, architectural decisions that will explain what we are doing and
guide us in moving forward.
-------------------------------------------------------------------------
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
