Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!network!ucsd!ucbvax!tut.cis.ohio-state.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
Keywords: MX2, process swapping
Message-ID: <1072@philmds.UUCP>
Date: 14 Aug 89 06:17:03 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> <194@crash.cts.com>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 32

In article <194@crash.cts.com> fgbrooks@.UUCP (Fred Brooks) writes:
|In article <1069@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
|>[about avoiding block in read/write on slow devices]
|
|I intercept the BIOS trap vector and add my own routine to do the BConin
|call. If nothing is waiting in the buffer then I swapout the current process
|, if a char is is the buffer it is passed on to the calling process and a
|countdown variable is set to say 100 so that when then next time the buffer
|is empty it won't swapout until it has checked the buffer a few times.

You'll have to be careful this BIOS call was not done from GEMDOS, I think.
I'm interested to know how you save a process's state.

|>P.S. The current version screamed for job control, signalling etc. so
|>that's being implemented right now (together with some system calls
|>like signal() and kill()).
|
|I would like a copy if you are giving it away with source.

The signalling stuff has been implemented. Now of course add job control,
so that a character typed from the keyboard (^Z or is that too overloaded
in GEMDOS?) can stop a process. I'll have to add a notion of background/
foreground, so that a background process is stopped when it wants to use
the console (read/write) and can be brought into the foreground.

You can have a premature copy if you want that (undoubtedly with bugs);
before I offer it to the sources/binaries groups I want to test it myself
when it is complete (I'm already thinking about pipes / interprocess
communication etc., so depending on whether this would come into the
first release, it could take a while).

   Leo.