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.