3.6) What about pre-emptive multitasking? (User / Machine interaction - Mac Programming)
Description
This article is from the Mac Programming FAQ, by Jon Watte h+@austin.metrowerks.com with numerous contributions by others.
3.6) What about pre-emptive multitasking? (User / Machine interaction - Mac Programming)
To the user, the Mac multitasking method, which builds upon each
application calling WaitNextEvent, GetNextEvent or EventAvail every so
often and the Process Manager/MultiFinder switching applications only at
such calls, is at least as good as preemtive multitasking, because the
present system priotitizes user interface responsiveness over everything
else. The only shortfall about this is formatting floppies, which locks
up the Mac CPU. This is because the Mac floppy controller is really
stupid, and would happen even if the Mac multitasked preemptively.
There IS "real" pre-emptive multitasking available for use in Mac
applications; the expensive way is buying A/UX 3.0 which can have Mac
applications written as UNIX processes; the cheap way is installing the
Thread Manager which will allow you to create pre-emptive threads.
However, the restrictions on those threads are the same as those on Time
Manager tasks: don't call any function in an unloaded segment, and don't
call QuickDraw or any toolbox call which may move memory (which are most
ToolBox calls; paradoxally, BlockMove is safe :-) as are, surprisingly,
FSRead and FSWrite). The latest word from Apple is that this
preemptive support is going away, to be replaced by something else in
Copland.
There are several problems with making the Mac OS preemptive; including
apps that draw outside their windows or directly to screen, user
dragging and other issues. The system is being reimplemented for 8.0
(Copland) to solve these problems.
Continue to:
My Books
