Article 168003 of comp.os.vms: On 18 Apr 1997, Glenn C. Everhart wrote: > The NT inner mode scheduling with only 2 modes reminds me rather strongly > of the way forks are handled in RSX11M and M+, which some of us remember > well... > > The VMS use of software interrupts was a device to avoid software polling > that was the alternative...and I'm not at all sure that a 486 or better > can't be equipped with something comparable. Recall the PIRQ on pdp11 > was at one time a separate circuit... From memory, the only use of the PIRQ in M/M+ was to fob off an FPP interupt to level 1... > You can replace multilevel interrupts by suitable software; I've done it > and so have many others. It may cost some speed (depending on the timings > of the circuitry in the full path) but the real question is whether > the resources to do so are available to spare. An interesting comparison from M+ is the single $FORK que, vs VMS's multiple levels, and the 4 levels of driver proi as well. The coment was, that the short code path was as good as prioritizing the fork levels. Almost all the time you only had one or 0 entries on the fork Q. Also, if the interupts did burst in all at once, the fork level processes had a good chance of running in priority order anyway. But all this changes if you are looking to putting 32-64 or more CPUs on a memory/IO system that won't die under the load. Then you are after every bit you can get, and a single fork process just won't even get off the ground! Hell, a 2 CPU M+ system is hit by modest lock contention in the kernel. BTW, dec had the x86 BLISS compilers, and all the rest, so that was no problem. ~Paul