OSDev.org

Is there any OS in which the window manager is always responsive? In which I can always click on the cross button to close the window and the corresponding program. I have used Ubuntu and Windows but in both of them the GUI, including the mouse, freezes on running any high-memory-consuming program.

Probably no. No GUI is perfect and can run so smooth that there's no lag.

utkarsh wrote:Is there any OS in which the window manager is always responsive? In which I can always click on the cross button to close the window and the corresponding program. I have used Ubuntu and Windows but in both of them the GUI, including the mouse, freezes on running any high-memory-consuming program.

Sorry for late reply, I have a bit of experience with this: I have seen the mouse remain responsive in Linux, and it was good. The window manager didn't, but just the mouse helped, and in any case, a powerful window manager can be a remarkably small program. I remember (vaguely) there was a specific extension to Xorg to make this possible. (I think it was XFree86 at the time, it was a long time ago.) This behaviour seemed to go away after some years; perhaps it only worked with the old standard X cursors or something.

Anyway, the trick is to prevent certain code and data from being paged out. It's that simple. The down-side is now you have some things which can't be paged out, and probably want to minimize the size of them. (Fancy cursors aren't that large, are they?) I also guess Linux devs thought it doesn't help to be able to click the close button if the application then has to be paged back in to run its close-window call-back just in case it wants to decide if it wants to pop up a confirmation dialog. (Repettitive language intentional.) I'm not convinced that's good reason to let pointer control be paged out. For one thing, it was much nicer to see where you're pointing so you can queue up clicks to be executed when the computer's ready. For another, in X with a decent window manager, there's always the option of force-killing windows, which is fine when you know the callback isn't going to do anything useful anyway.

Now I think about it, this is a notable part of why I feel Linux has been going downhill. It's a loss of control, tying the user down to watch the computer chug away for minutes so they can do something about it, where formerly you could just queue up clicks and walk away. The alternative is to go to another computer and use text over ssh, which, as it involves waiting for the ssh process to be paged back in and other things, is not nearly as good as just being able to click with a responsive mouse.

utkarsh wrote:Is there any OS in which the window manager is always responsive?

Yes. It's called X, which is a separate process as well as its window manager, and both can act even if the program is frozen. One window manager, WindowMaker for example will forceably kill the application if you double-click on the close icon, which works even if the application can't respond to SIGTERM or SIGQUIT signals.

Now if your kernel is lagging and can't serve interrupts in a timely fashion, then the user will experience unresponsiveness in the entire system, not just in the window manager, but that's a totally different question. If the window manager doesn't get the pointer coordinates from the kernel in time that doesn't mean the wm is unresponsive.

Cheers,
bzt

Yes there is (or, was?) such an OS, but you could say this was an achievement through limitation as much as ability.

AmigaOS did not make use of memory protection / an MMU (because many Amiga PCs didn't have one, out of the box). This had several effects:

• Inter-process communication was very efficient, as all you had to do was to pass around a pointer.
• Context switch costs were very low (no address space switch, no cold Translation Lookaside Buffer, ...).
• Memory was never "paged out". You either had enough memory to run all the applications you wanted, or you didn't.

Plus, user feedback -- the effect of that GUI button going to the "clicked" state -- had one of the highest priorities in the system. It could take some time for the application owning the window to come around in the round-robin schedule, acknowledge that "click", report back "I did what that click asked me to do", then the Workbench (what passed as a "Window Manager" on AmigaOS) coming round on the schedule, acknowledging that message from the application, and returning the button to the "unclicked" state (or closing the window or whatever that click was intended to achieve).

But you got the feedback "I received your click, please wait while I process this" pretty much right away.

There were situations where this would fail to happen, but that usually was due to another effect of not having memory protection: Some bug had started to eat away at the OS' innards, and things did no longer work as intended.

It might have been priority rather than pinning in XFree86. I can't remember, it was too long ago and because it's X I'm not going to look.