🚀 go-pugleaf

In article <416q7e$6ik@bug.rahul.net> Bill Moyer, ttk@rahul.net writes:
>>Myth #1 Copland will have preemptive multitasking.
>>  Apple has decided to phase preemptive multitasking accross 2 major
>>versions of system software. This is to ensure compatability. You will
>>have to wait until Gershwin for completely preemptive multitasking, but by
>>then, all the programs will be writen to take advantage of it and will be
>>instantly compatible.
>
>  Could someone in the know let me know something?  Why would 
>pre-emptive multitasking break apps made for co-operative 
>multitasking?  Properly done, a process doesnt "know" when 
>it's been pre-empted.  Its state remains the same before and
>after the task switch.
>  Presumably there are MacOS-specific issues I don't know about.
>Perhaps apps diddle with system data structures as they set up
>a co-operative task switch, and you don't want the pre-emptive
>multitasker to interrupt them in the middle of it?
>  Sort of along the same lines, what would an app need to do to
>take advantage of pre-emptive multitasking?  The idea is that 
>the task-switcher will behave exactly the same, regardless of 
>what a process does or doesn't do..  Again, I suspect there are
>MacOS-specific issues I'm ignorant of.
>

The major problem is the same reason why protected memory cannot be 
installed right away. In the past the easiest (or only) way to achieve 
certain things was to fiddle with certain global data structures. As 
anyone who knows OS's will tell you, in a pre-emptive environment such 
accesses have to be atomic, usually surrounded by mutexes. Needless to 
say the current mac apps do not use mutexes because their access was in 
the past automatically atomic, by virtue of there being no 
pre-emptiveness. 
A related and sowmehat similar problem is that many of the Toolbox 
routines rely on global state to hold variables across calls, and that 
global state is often system global not process global (ie many lowmem 
variables). In this sort of environment routines are not re-entrant which 
precludes pre-emption. 
The above statement is of course a simplification---what one would do is 
define a sempahore to guard access to the globals and rely on that to 
serialize requests. Such a sempahore solution is what is used for Win16 
apps under Win95. 
A similar sort of solution is used by Copland. The "System 7" environment 
including most of the toolboxes and current apps is juggled by the 
process manager so that only one system 7 app is active at a time. 
However that current system 7 app is pre-emptively multi-tasked against 
new Copland savvy apps. (All this actually happens at the thread level 
rather than the app level but the idea is the same.)
Many new parts of the OS (ie Open Transport and the new file system) will 
run as separate protected servers that cope with pre-emptive multitasking 
just fine. But the thread of an app that relies on user-interaction (ie 
using the Toolbox) will still run co-operatively scheduled with the other 
system 7 apps (though it can spawn off computation or IO threads that are 
pre-emptive).

So what does this mean?
It means that developers can start to get involved with pre-emptive type 
issues like sempaphores right away.
It means that the OS will already in Copland be capable of running some 
threads on separate processors, ie multi-processing. 
It also means that standard mac apps will, unfortunately, continue to be 
able to lock up the machine for practicval purposes for another round of 
the OS. (What I mean by this is that even though background servers and 
threads will still be running happily, the user interface can be locked 
up by a single app that doesn't call WaitNextEvent().) However it is 
likely that, if that app has to be killed manually (eg by 
command-shift-escape), the system 7 world is more 
likely to continue going, and if the system 7 world is taken down 
(because the app was modifying global dat structure when it died) the 
rest of the OS will still be around and only the system 7 world will need 
to be rebuilt, not a complete reboot.

Maynard