Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uunet!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.atari.st
Subject: Re: GEM multi-tasking interface (please!!)
Message-ID: <7845@cbmvax.UUCP>
Date: 6 Sep 89 16:33:59 GMT
References: <8909040249.AA18031@ucbvax.Berkeley.EDU>
Organization: Commodore Technology, West Chester, PA
Lines: 25

in article <8909040249.AA18031@ucbvax.Berkeley.EDU>, MEGGIN@vm.epas.utoronto.CA (David Megginson) says:

>    The accessory can either switch between applications using a
> timed interrupt, or switch every time there is an OS call.  

This is much more difficult than it might seem.  I don't know much about
GEMDOS, but I suspect that none of the function calls are re-entrant.  That
means that interrupt driven (transparent, etc) multitasking is out.  The
second problem is how to manage the global data areas that a program uses,
but if you're willing to create a new kind of program that's designed for
multitasking, this gets much easier.  The example of Apple's Multifinder 
shows one case where an operating system not designed for multitasking can
support a limited form of multitasking.  Multifinder swaps tasks when a 
particular function call is made -- it's not likely safe to swap tasks on
any function call in such a system.

Once you get tasks running together, the next thing that's necessary is control
of task access to shared resources.  For example, it should be OK for any 
number of tasks to read a single file, but only one should write it.

> BITNET:		David Megginson <meggin@vm.epas.utoronto.ca>
-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough