Wimp 2 - what was wrong with it?

Wimp 2 – Pre-emtive multitaking system

http://www.nedprod.com/programs/RISC-OS/Wimp2/

I remember trying it, and it appeared to work OK. But it never caught on.

Could it have any relevance now?

It could be a useful reference for what things we need to watch out for when we start adding PMT to the OS. I’m not sure whether we’d be able to use the code directly, though – I’ve never looked at the source so I’m not sure exatly how it hooked itself into the OS or how well written it was.

The impression I have, is that the PMT subsystem, was itself a CMT process. Therefore it is a stepping stone to a full implementation. (ie to get the software that uses it written).

(note: a big IIRC)

My limited understanding is as follows:

It hooks up a routine on a timer interrupt (OS_CallEvery I think)

The routine on the timer interrupt sets up a transient callback to happen when the machine next drops into user mode

The transient callback routine, which is running in user mode, calls Wimp_Poll on behalf of the application

That callback routine queues up events received from Wimp_Poll and feeds them to the application whenever it calls Wimp2_Poll

The effect is that the application is preempted and the events are only fed to the application when it is expecting them. I’m not sure how the Wimp2 Patch handles feeding events to apps that only call Wimp_Poll, but however it was it didn’t work too well.

The actual idea of using a transient callback works surprisingly well: IIRC this is how pthread support in UnixLib works, and that’s what enables Firefox to operate. That means it’s been fairly well stress-tested, so that would probably be a good place to start looking for example code.

Yes, that sounds about right.

I’m not sure how the Wimp2 Patch handles feeding events to apps that only call Wimp_Poll, ...

At a guess I’d say that it patches the application to call Wimp2_Poll instead (or installs itself on the SWI vector and traps the SWI directly).

... but however it was it didn’t work too well.

This is the most important thing IMO - we need to make sure that any changes we make to the OS to support threading break as little existing (abandoned) code as possible. So if we want to support threading without limiting it to just programs that have been rewritten/updated to take advantage of it, we have to be very cautious with what we change.

I think much of the perceived stability problems of Wimp2 were in fact applications that were simply “patched” to use Wimp2 instead of Wimp. Apps that were written to properly use Wimp2 did not suffer from stability problems. I did some fairly intensive testing back then, and Wimp2 successfully allowed CDBurn to multitask during writing a CD.

I did some fairly intensive testing back then, and Wimp2 successfully allowed CDBurn to multitask during writing a CD.

Wow. That is a powerful recommendation. Thanks, Steffen.

So if we want to support threading without limiting it to just programs that have been rewritten/updated to take advantage of it, we have to be very cautious with what we change.

Don’t forget though, even if a PMT system only shows advantages when no CMT programs are running, we would still be better off than without it.

Would the most likely scenario be that running CMT programs would be a hit, but not as bad as using the current system would be?

Would the most likely scenario be that running CMT programs would be a hit, but not as bad as using the current system would be?

Yes.

This is just my opinion, but even though this system wouldn’t be any better for existing software, at least right away (CMT programs could still freeze the entire system,) it does have the huge advantage that a library of PMT software could be made, eventually removing the need for CMT software, and gradually increasing the performance of the system as less CMT software is used.

Isn’t the main issue with CMT that it requires the application to behave well, for the system to remain responsive.

If a PMT system for new apps were introduced, any current app that behaves well shouldn’t really mess the system up (if it runs OK under the current system), it would only be badly behaved apps that cause issues.

As I understand, it would be better for ported programs that were designed for PMT systems and also allow for future multiple processor systems to be used efficiently.

Yes and No.

The main issue is that you must break complex calculations into several pieces when using CMT, and that is sometimes difficult to implement, especially (as you noted) when porting from a system that did not have the same restiction. This makes porting more complicated and breaks the original structure (making it more complicated to keep up to date with changes on the original).

The ‘behave well’ issue is even an advantage of CMT I think. The good responsiveness of the RISC OS has a lot to do with the fact that (a) for a developer it’s important (easiest) to process every program action in one WIMP cycle – and fast -, and (b) a program bad/irresponsive enough to influence the whole system gets kicked from the user’s Harddisk quite fast.

So the only major advantages to PMT are for ported programs and to utilise multiple processors effectively?

So the wimp2 approach could be quite an effective way to go. Ported programs would use it, old programs wouldn’t. New programs could go either way.

Could a system be implemented whereby the main process runs in the normal way and any spawned child threads are time sliced in a PMT manner. This would have some limitations but maintain 100% backward compatibility and solve most issues. I think a full-blown conversion of RISC OS to PMT would be a nightmare to implement causing all sorts of issues, and personally think the effort could be better spent.

Could a system be implemented whereby the main process runs in the normal way and any spawned child threads are time sliced in a PMT manner.

Yes – that’s basically what UnixLib’s pthread support does.

I have used GUIs on Linux, Windows and RISC OS systems. The first two were PMT systems and, IMHO, gave a response far inferior to that of RISC OS. Why? Because a decent UI ought to give the user timely notice that her inputs have been noted. Why, on the Windows XP system, do I have to wait ages before I know that Firefox is going to open, and then eventually find three windows opened instead of one? It is human nature to press a button again if the first press produces no response – the fingers simply respond this way however much the brain says wait . Now it may be that, with a bit of tuning, a PMT operating system can respond in an appropriate manner. But in practice they rarely do. Every input should trigger an immediate notification that the matter is in hand. That is why I revert to using RISC OS with relief. Can anybody tell me of a PMT OS in which a GUI has been properly designed, to take human physiology and psychology properly into consideration? I do not think this can be said of Windows or for what pass as GUIs on Linux systems.

Warning: Big sprawling message follows…

The first two were PMT systems and, IMHO, gave a response far inferior to that of RISC OS.

I don’t use Linux enough to comment, but I do use XP. I can say that for all of the benefits that XP’s PMT offers over RISC OS’s CMT (such as not freezing when the system is printing), it also has its own issues. While a borked RISC OS task can stall the machine until it is killed, a borked Windows task could easily become a zombie task with a blank (non redrawn) window and an utter inability to respond to any window furniture. So you may have a large dead window that won’t go away. Thankfully an app getting into that sort of mess is fairly rare, most can be killed off with Ctrl-Alt-Del, though I have had scanner driver frontends that crashed is such a way that the system couldn’t kill them. There’s probably some tool on SysInternals, but I decided a reboot would be less hassle.

Why, on the Windows XP system, do I have to wait ages before I know that Firefox is going to open,

Because Firefox is the resource hog to trounce all resource hogs.

and then eventually find three windows opened instead of one?

Impatience? ;-)

Really – the only sensible thing to do with Firefox is click its icon, then go put the kettle on.

a PMT operating system can respond in an appropriate manner.

It did. Watch carefully. Your mouse will momentarily become whatever hourglass your system uses. That means Windows is starting the task. From that point, it’s up to the task to continue loading itself and inform the user – this is when an annoying task would pop up a “splash screen”. Indeed, I suspect the prevalence for splash screens in the last decade are exactly to let the user know that “something IS happening” because loading apps is a long and tedious process.

I started Nero’s QuickieSimple version on my P4 machine the other day, and it stuck swish wibbly lines on my screen for a while. Why? Because it took something like twenty five seconds for the application to load.

I guess it is perhaps a psychological flaw in PMT systems? I think that if a user double-clicks a program’s icon, the system should devote the majority of processing time (like 90% or more) to that task until it first calls Yield. Why? Easy – the user has clearly signalled that THIS is the task they want to be using NOW, so give it a boost to load quicker. The machine should not time slice normally until the app is loaded.
Doing this might allow stuff to start up in a timely manner.

This is why RISC OS software often loads blinding fast. The system is “frozen” between app start and the start of the polling loop. This time contains all of the app init stages, which end up with 100% system time. Obviously this means everything else stops – but I can’t say I’d cry if NetSurf freezes for the time it takes OvationPro to load. It’d rather be more miffed if OvationPro took twice as long (or longer) because RISC OS kept NetSurf (etc) running.

Every input should trigger an immediate notification that the matter is in hand.

It does. It’s just the notification (the hourglass) is brief and subtle.

That is why I revert to using RISC OS with relief.

I’m writing this on NetSurf. While XP is a more powerful system, I don’t need to watch animé today (it’s on my phone) and I really don’t feel like dealing with a system that pops up notifications and dings after I have dismissed them.

[technical: XP was the first version of Windows to pass ding messages to a separate media “server”. Older Win32 builds used to play the ding WAVs directly. The problem is that XP will now send a message to the server saying “play this ding”. If the ding has been played recently, it will happen. If it has not been played, the server will need to find it, load it, then play it. And it is multitasked, so there can be a distinctive lag between when the ding should happen and when it does.]

Can anybody tell me of a PMT OS in which a GUI has been properly designed, to take human physiology and psychology properly into consideration?

Sadly, I think most of the PMT/CMT arguments exist on a purely technical level – which can switch the most tasks in the least time, etc.
I wonder if anybody cares that much about the end users any more, what with the annoying-as-hell propensity for popular applications (and entire Linux distributions) to arbitrary “improve” their entire UI.
I am (still!) running Firefox 12 on my EeePC. The P4 machine is running the current version, and I’m quick sick of the tweaks and changes to the API. I’d like my browser to have security issues fixed. That’s all. Leave the UI the hell alone. It wasn’t broken forty versions ago, it isn’t broken now. Grrr.

Don’t get me started on the YouTube app.

I do not think this can be said of Windows or for what pass as GUIs on Linux systems.

What is important to you?
Or, to put it another way… load !Paint. Create a new sprite of size 640×480 with no name. Paint will pop up a message saying “You need to give the sprite a name”.
Is it justifiable that this message stall the entire system? I mean, I could understand if it was a system critical sort of message (Drive empty, Disc full, Disc error, etc) but Paint telling you the sprite needs a name?

Sure enough, there are various attempts at multitasking messages, but they need to be written with a lot of care, and none of them are implemented at system level.

Ultimately, what I think CMT vs PMT comes down to is “priority for the current task” against “priority for every task”. PMT systems can allow more fine-grained control by assigning a task a ‘priority’ level that can influence its timeslice, but as far as I’m aware there isn’t usually a method to single-task so a PMT app will need to be aware that there will be ‘n’ other tasks running at the same time.
On a CMT system there is usually no concept of task priority. The programmer needs to utilise features of the platform (such as pollmask and PollIdle) to guide the system for the times when the app doesn’t even need to be called. Nothing happening? The app can be ‘dormant’ until such time as something does happen. Plus CMT offers potentially better return times. Let’s say an app is timesliced for 2cs, but it can do what needs done in 7ms. What happens then? That cannot be answered as it no doubt depends upon the app and the OS. The best case is the app can signal to the OS to forfeit its time. The worst case is the app twiddles its fingers for the remaining 13ms.
This isn’t the case with a CMT system such as RISC OS. It is intrinsic in how the system is designed that the app is entered with an event to deal with, and the app exits back to the system once it has happened. While slow programs (hello ChangeFSI) can stall the system for lengthy times, in general an application consumes exactly as much time as it needs.

That isn’t to say that RISC OS wouldn’t benefit from some PMT-like behaviour. Think how much better ChangeFSI’s lethargy could be if it was possible for the Wimp to switch to a timeslice mode where it will let a “busy” app run for n centisecond chunks around other programs. The Wimp can queue important events, discard ones that are likely to be invalidated by the delay, and just enter/exit the app outside of its central polling loop. The app itself won’t know whether it ran timesliced or whether it ran singletasking.

Warning, windows related stuff.

There’s probably some tool on SysInternals

I think that source would bring up “Taskkill”, elsewhere you’d find GUI driven stuff like Whatsrunning – it’s sort of like a windows taskmanager on steroids

Features in there like looking at bits inserted into your startup are quite handy too.

My standard recommendation as a quick test of improvements is to type NET STOP THEMES at an admin command line. I you like that set the startup state of that service to disabled.

I use Process Explorer. A useful “Find” for handles. Useful when the stupid filesystem “Open” (or “Save” dialogue) leaves a removable device “open” meaning it can’t be safely ejected. Find out what’s holding the device open, can the handle be force-closed?, and then the device correctly ejected…

I might be one of the few people in the world that likes the FisherPrice theme. It helps to remind me that I’m using XP (so don’t press ^U to delete URLs in Firefox…).