Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!mcvax!hp4nl!phigate!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.sys.atari.st
Subject: Re: Multitasking on the ST
Message-ID: <1076@philmds.UUCP>
Date: 16 Aug 89 08:58:52 GMT
References: <8908021826.AA05333@ucbvax.Berkeley.EDU> <15627@watdragon.waterloo.edu> <1989Aug4.173233.8259@sj.ate.slb.com> <1067@philmds.UUCP> <1989Aug11.175942.6534@sj.ate.slb.com> <1069@philmds.UUCP>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 102

Sorry to bother who it might not concern, but due to a mailer problem I'll
have to try it this way.

	Leo.


From phigate!hp4nl!hp4nl.nluug.nl!cs.utexas.edu!MAILER-DAEMON Wed Aug 16 09:56:41 1989
Received: by dts.philips.nl; Wed, 16 Aug 89 09:56:31 -0200
Received: by philips.nl; Wed, 16 Aug 89 09:31:43 +0200
Received: from [128.83.139.9] by hp4nl.nluug.nl with SMTP
          id AA22560 (5.58.1.14/2.14); Wed, 16 Aug 89 08:49:38 MET
Date: Wed, 16 Aug 89 01:49:07 CDT
From: phigate!cs.utexas.edu!MAILER-DAEMON (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Posted-Date: Wed, 16 Aug 89 01:49:07 CDT
Message-Id: <8908160649.AA02583@cs.utexas.edu>
Received: from uunet.UU.NET by cs.utexas.edu (5.59/1.39)
	id AA02583; Wed, 16 Aug 89 01:49:07 CDT
To: <@hp4nl.nluug.nl,@phigate:leo@philmds>
Status: R

   ----- Transcript of session follows -----
Unknown host: meadow
550 ... Host unknown

   ----- Unsent message follows -----
Posted-Date: Wed, 16 Aug 89 07:58:25 -0200
Received-Date: Wed, 16 Aug 89 01:49:07 CDT
Received: from uunet.UU.NET by cs.utexas.edu (5.59/1.39)
	id AA02571; Wed, 16 Aug 89 01:49:07 CDT
Received: from hp4nl.nluug.nl by uunet.uu.net (5.61/1.14) with SMTP 
	id AA05718; Wed, 16 Aug 89 02:48:54 -0400
Received: from phigate by hp4nl.nluug.nl with UUCP via EUnet
          id AA22332 (5.58.1.14/2.14); Wed, 16 Aug 89 08:12:38 MET
Received: by philips.nl; Wed, 16 Aug 89 08:02:59 +0200
Received: by dts.philips.nl; Wed, 16 Aug 89 07:58:25 -0200
Date: Wed, 16 Aug 89 07:58:25 -0200
From: leo@dts.philips.nl
Message-Id: <8908160558.AA29843@dts.philips.nl>
To: meadow!bill@cs.utexas.edu
Subject: Re:  Notes on multitasking

Hi Bill. In your letter you write:

|I really wish it would rain more in California.

Sometimes, when it's been good wheather for a long period (that is a
rare occasion here in Holland, but this summer was like this) I long
for a few dark and rainy days - ideal for a nice project.

|You know that when you are going to multitask programs with disk usage,
|things such as the DTA address, Fsfirst-Fsnext chains, current drive and
|directory, and probably several other things have to be saved on context
|switch.  You may also have a problem with the OS's terminate calls.

Yes, I know (B.T.W. several people told me this; there seems to be both
a fairly large interest in this subject as general knowledge of the
traps and pitfalls). The strong point of my design is that it is
synchronized with GEMDOS calls (and for CPU bound processes there's a
different solution). GEMDOS calls, as you'll probably know, save their
registers on the current process's basepage and stack. As far as DTA
address, current drive / directory is concerned, this is also
information that is kept on the basepage with the process.
Fsfirst-Fsnext chains are kept in your disk transfer buffer (the
information to find the next is found from the first 20 bytes). This
buffer also resides within your process (and DTA, a pointer on the
basepage, points to it).

Terminate calls are no problem at all. Processes that run detached ('in
the background') get a special parent: a basepage in the multitasking
kernel itself which returns control to the dispatcher (that frees the
process slot). Ordinary processes just end the usual way (their process
slot will be taken again by the parent). I even implemented kill() and
signal() calls to be able to stop and restart or kill processes (even
coredump). Also alarm(), sleep(), and pause() have been implemented
(yesterday).

|I tried a number of methods for multitasking including Desk Accessories,
|VBI, and 200 Hz system timer - all before I found out about saving disk
|info.  Maybe it would work better with this implemented.

You have to take great care when interrupting GEM, this is not built to
be multitasking. I use VBI for CPU bound processes; after a time slot
has been used up, and if the process is in user mode, it switches to the
dispatcher as through a GEMDOS call (the registers are saved on the
process's basepage and stack), since I know I'm not interrupting GEMDOS
right now.

|
|What we really need is a multi-tasking TOS 2.0 on ROMS (dream on - Atari will
|release it's TOS/Unix machine and then forget about ever multitasking TOS)

Sure, but like TOS 1.4 this can take quite a while; for the GEM part it
would mean a general redesign (the GEMDOS part, in all its simplicity, is
very easy to make multi-tasking; that's just what I did).

|Good luck - it should prove interesting.

It sure is; thanks for your interest & concern.

Cheers,
         Leo.