how about COMPLETE MULTITHREADING

solrac

solrac

Mac Ninja
This should be the future of OS X.

Currently, completely separated apps work great. If explorer is hanging up and freezing, I can click on TextEdit and it instantly frees up the computer. If the Finder is freezing or thinking, I can instantly click on another program. I can always use the Dock since that is a separate application as well. Even if the Dock AND the Finder were crashed, you can still use cmd-option-escape and bring up the force-quit window. This is also a separate application.

But Apple should go beyond this. They should engineer OS X to automatically make every element of the OS a separate "application" if you will.

The Close, Minimize, and Expand buttons on every window should be separate applications. Even if explorer is crashed, those buttons should light up when the mouse rolled over them, and could close (or force quit) a crashed explorer window.

That's right, Explorer would not be crashed. Only one particular window in explorer would be crashed. The menubar at the top of Explorer should be another separate process. If an explorer window is crashed, File.. new should still be selectable, and a new explorer window could be opened. The crashed window would be unusable, but the window-toolbar buttons could still minimize it, close it, or expand it. Selecting File ... Quit should not be explorer quitting itself but the system ending the explorer process. File ... New should not be explorer opening a new window, but the system giving the "explorer kernel" a new window command. This way Applications themselves are multithreaded.

The Finder should be the epitome of this. If a finder window is freezing or taking a long time (such as loading an iDisk, or renaming a file sometimes, or something that hangs it up), a new window should be able to be opened. A new folder can be made. Every separate process in the system should be like it's own application, so that only processes can crash, not entire applications.

If you typed cmd-opt-escape (force quit window), you would not see a list of apps you could quit. You would see the apps with a drop down arrow. Click on finder. You would see every process running under finder: "List iDisk contents", "Rename Folder", "open window 1", "open window 2", etc. etc. You could terminate any process within Finder. Or the entire App itself if you'd like.

This would turn Mac OS X from rock solid, into... invincible.
 
Uh, hate to break your bubble, but that isn't Apple's job (for the Finder, yeah it is, but not for IE)...

There is already 'COMPLETE MULTITHREADING' as you put it in OS X, it is just that Apple cannot shove it down the programmer's throat. Each application programmer is entrusted with the authority and responsibility of properly splitting up the work of the app into multiple threads. PLUS, there is the issue of making apps unstable by using multiple threads for your app. If Apple crammed this issue down programmer's throats, deadlocks could start occuring, locking up the whole app anyways because the app programmer and the Apple programmer have different programming styles.

Sure you could split the event work onto a whole new process, but that is just going too far. When you already can have many threads in one process, there is no need to start forking new processes. Each process' memory is protected, then requiring even MORE work just to allow the actual app to get access to its menus and other UI elements.

IE could be fairly solid and not lock up, but they would have to manage their threads intelligently. If you don't, you might deadlock, kill a thread you are relying on at the wrong time, and so on. Both of those mentioned situations will lock up AT LEAST the two threads involved, possibly the app itself. Sure having a single-thread app lock up is no fun, but who knows, IE may be multithreaded, but poorly.

I had many of my own threading issues, including some nasty ones from me not setting a flag BEFORE my threads get spawned (and pre-empt my main thread), causing them to die before they even get started.

Sure this is possible, but the effort required for such a task could be much better spent increasing the feature base and addressing the current issues with the OS, and be assured they were getting somewhere. This task would be a wild goose chase that would cause more problems for programmers than it would solve for users.

------------
Additional:
------------

I completely forgot about one thing you mentioned until just now:

You referred to something where going to 'File -> New' would be issuing a command to the 'Explorer Kernel' rather than 'Explorer opening a new window'. To be blunt, this already occurs, and has for a LOOOOONG time.

The system handles the events, granted this is on the application's main thread or event-handler thread's CPU time. Under the Carbon/Cocoa event scheme, when you click on 'File -> New', it THEN calls our code to handle the event in the way we see fit. If 'New' is supposed to mean a new browser, then we create one, if 'New' is supposed to mean a new method to destroy the universe, we print it out on the screen.

Classic MacOS required the app to poll for events, but very similar situation. After you successfully polled for an event, you took a look at it to see what it wanted your app to do.

Nothing would be gained, since it is already so.
 
Another issue is the amount of processing required by the OS to keep track of all the threads. I was doing some testing a few years ago on multi-threading and load testing some hardware we were thinking of using as a large server. I created 10,000 separate threads and the OS took almost all its effort just keeping track of that many.

We OSX we have seen a dramatic increase in stability at the expense of speed. By increasing the number of threads we would potentially see some increase in stability, but again at the expense of speed because the processor would be utilised keeping track of the increased number of threads.

R.
 
If I'm not mistaken, the Be operating system did something like this. Everything was a thread. I have no idea how it worked though, since I never actually used the operating system.

But yeah, it's mainly the programmer's responsibility on to do this on the Mac.
 
Originally posted by Krevinek

...

You referred to something where going to 'File -> New' would be issuing a command to the 'Explorer Kernel' rather than 'Explorer opening a new window'. To be blunt, this already occurs, and has for a LOOOOONG time.

The system handles the events, granted this is on the application's main thread or event-handler thread's CPU time. Under the Carbon/Cocoa event scheme, when you click on 'File -> New', it THEN calls our code to handle the event in the way we see fit. If 'New' is supposed to mean a new browser, then we create one, if 'New' is supposed to mean a new method to destroy the universe, we print it out on the screen
Click to expand...

That's not what I meant. I meant that File.. New in explorer is a command within explorer.

In my example, File.. New would be the "menubar" application sending a File..New message to explorer

Maybe my OS functionality was just a dream... but maybe it can be done in the future...
where programmers don't have to make everything multithreaded, the system does it automatically. Maybe with much more powerful chips, too.
 
Originally posted by solrac


That's not what I meant. I meant that File.. New in explorer is a command within explorer.

In my example, File.. New would be the "menubar" application sending a File..New message to explorer

Maybe my OS functionality was just a dream... but maybe it can be done in the future...
where programmers don't have to make everything multithreaded, the system does it automatically. Maybe with much more powerful chips, too.
Click to expand...

Actually the only difference is on who's CPU time that the menu handling is done. As it stands, the majority of it is done on the app's CPU time, since it makes sense to run it there, rather than in kernel space which is BAD. Even so, there is an app that handles a majority of the main UI issues, and we really shouldn't be having bunches of apps floating around opening up precious sockets just to pass data between memory protection boundaries. It makes things a little too complex, and sucks up network resources for other purposes.

The reason why programmers are the ones being told to make it multithreaded is because the programmer usually knows the best route to efficiently multithread their app, not Apple...

This thread makes mention of a Cocoa object to quickly and efficiently toss tasks off the thread that handles events. This is key since only the thread(s) involved with the lockup are affected (usually blocking for something that will never arrive/occur), allowing the thread that handles events free to handle them. The result is what you are asking for.

Instead of pointing at Apple for the solution to this, point at Microsoft and the other programmers making mistakes with the design of their programs. Hell, if I ever release a completed app, I would feel insulted if the blame for my app's speed/responsiveness was placed into Apple's lap.
 
Sounds like windows IE, which spawns a new program for each new window. So it could be odne if developers wanted it to be done.
 
You must log in or register to reply here.
Back
Top