RE: CSP and Isolates

[Tony Gore <Tony@xxxxxxxxxxxx>]

Peter wrote:

"Observation: I have problems from Windows applications interfering with each other anyway.  I suspect these are race hazards arising from foolishly starting them up in parallel (too rapid double-clicking) as they compete for resources - like the network or disk - without bothering to synchronise? But they can lock up anyway at unpredictable (and unrepeatable) times, which may be due to internal errors or - maybe - interference between applications ... who knows?

Question: if there are interference problems between separate Windows tasks, why should I have confidence that there won't be interference problems between Isolates?  I guess the answer is that it's because it's the JVM that's managing them - not Windows.  But who's managing the JVM?"

>

This is not just a question of too rapid double clicking. When an NT4 server starts, it is possible for processes to start before the processes that they depend on. This is handled in a number of ways - some processes retry several times; another method is there is an obscure documented way in which you can go and manually edit the dependencies, so that a process is not started until the processes it is dependent on are up and running. It is possible (and I have seen it happen) for systems to actually deadlock if you logon to an NT/Win2k system as soon as the prompt occurs and before all the services have started. Still, I suppose you get this on something that requires 900 threads to operate as a file server, web server and email server.

If you really want to see how not to write processes, then NT4 is one of the best examples of how not to. The original NT3.51 was a nice and reliable system, but the performance was not good enough for Microsoft, so they then allowed device drivers to bypass the HAL (Hardware Abstraction Layer) and deal with some of the hardware directly. There are some other wonderful little features - few people know that NT4 (and Windows 2000) have several levels of priority for processes. At first, I could never understand why GEAR (used for writing CDROMS) took 100% of CPU power to erase a CD. A closer look revealed that all the core modules in GEAR ran at real-time priority, which means that such a process only gets to redraw its screen window every few minutes. When I migrated to a 2 CPU machine, at least one CPU was left free to do some real work.

Most applications now seem to be even more badly written than they used to be - the number of starved threads seems to be increasing - if you monitor CPU usage, it remains low, there is no disk activity and yet it takes applications seconds, or tens of seconds to switch tasks - Adobe's Photoshop 6 is a prime example of this - 2 CPUs and 512M physical memory, a fast graphics card and a 10 second task switch with a 10k GIF file.

I am not sure whether to view the next OS move (to .NET) with amusement or fear, as I don't suppose that Microsoft will either do a proper deadlock/livelock analysis on the OS or do anything (other than lip service) about security. Most of the patches I have to apply these days to protect against security holes appear to be due to badly behaved processes and unpredictable error behaviours.

Tony Gore

email  tony@xxxxxxxxxxxx (alternative if problems tonygore@xxxxxxxxxxxxxx)
tel +44-1278-761001  FAX +44-1278-760006  GSM +44-7768-598570
URL: www.aspen.uk.com
Aspen Enterprises Limited
Registered in England and Wales no. 3055963 Reg.Office Aspen House, Burton Row, Brent Knoll, Somerset TA9 4BW.  UK