> [...] > > Definitely. > It gets worse actually, the whole domain/assembly design of .net and > mono seems to kind of assume that there's another OS layer underneath > with things like processes.. which doesn't necesarily have to be the > case in a managed OS > Afterall, processes and domains overlap a great deal when it comes to > functionality. > We probably have to have some sort of internal 'domain/process' > classes and expose functionality > trough an external 'domain' class that the applications actually see.. > > It still requires some thought, nothing is set in stone as it is... [Jonathan Dickinson] Sorry Sander, I really use ASCII in email because I can't really see another way of doing it. Can't you copy it into notepad/vim? Maybe we can set up something for creating such artwork on the website (a flash app perhaps?).
Okay, cause we are writing a thread scheduler. Are we wasting our time? I know it's a basic prerequisite of an operating system. But beg, should we not put more thought into it before we write it? Threads have served us well for what? 30 years? Are we still holding on hydrocarbon technology (you know, petrol/diesel is obsolete, but everyone uses it because that the way it is done)? What could we do instead of threads? Let's get the basics down. What we need (I luurv ASCII art :): +---------------------------+ +---------------------------+ | PROCESS | = IPC = | PROCESS | | SUB-PROCESS | SUB-PROCESS | = IPC = | SUB-PROCESS | SUB-PROCESS | +---------------------------+ +---------------------------+ So that's the way we see it today. I know the scheduler will be a nightmare to implement, but I saw the gist of it in old posts to the mailing list. / = IPC (horizontally i.e. "<=> IPC <=>" ) +-------------------------------+ | PNODE | | PNODE / PNODE | | PNODE / PNODE | PNODE / PNODE | | PN/PN | PN/PN | PN/PN | PN/PN | +-------------------------------+ So now there is no such thing as a process. Every process has its own stack/heap which sits 'on top' of its parent stack/heap: as does everything else. They can all communicate directly with their parent but must communicate via IPC to their siblings' stacks/heaps (which makes things a lot safer IMHO). It would practically force developers into a good programming paradigm: +---------------------------------+ | CONTROL | | UI / IO | | EVENTS / DRAW | CDR / HDD / NET | +---------------------------------+ So what we are talking about is OO within threads. For those of you who use Windows, imagine what fun it would have been if MS implemented it like this in the first place. Explorer.exe wouldn't freeze every time you looked at a CDROM for the first time :(. A lot of threading issues would also fall away because the developer would be required to use a reliable communication path. As per the above example: +---------------------------------+ | CONTROL | | >>>>/>>V | | / ^ | V / / | +---------------------------------+ Jeez, IPC would become a convenience here, we could just write it into the main process. We would land up with this!!! +---------------------------------+ | ROOT V<<<<<<<<<<<<<<<<^ | | GAME V | EVIL CHEATS ^ | +---------------------------------+ Wow. I must say that is unity at its best. I do know that I can be a bit ambitious at times, so do tear my idea apart :). > > [...] > > Well we have no IO yet, nor a JIT compiler.. i'm not entirely sure > what problem you're trying to solve here... > We could use a function which can execute a binary resource perhaps.. > Might be usefull to start with drivers.. (especially the IO driver! ;) > [Jonathan Dickinson] Just thinking ahead :). I just think that we don't want to have to write a JIT until we actually need it (which is never, really, we could just AOT everything every time it is changed). 'nor a JIT compiler' is precisely what I am getting at: we need to have something in the mean time. When we include JIT it must fall away by changing/including one line (ideally). Jonathan Chayce Dickinson ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
