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.