Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: Copper mystery Message-ID: Date: 2 Apr 91 19:53:49 GMT Article-I.D.: overload.dillon.5879 References: <5343@mindlink.UUCP> <1991Apr2.005933.28315@menudo.uh.edu> Organization: Not an Organization Lines: 41 In article <1991Apr2.005933.28315@menudo.uh.edu> honp9@menudo.uh.edu (Jason L. Tibbitts III) writes: >In article <5343@mindlink.UUCP> Ed_Meyer@mindlink.UUCP (Ed Meyer) writes: >>> dillon@overload.Berkeley.CA.US writes: >>> >>> Actually, as per my previous message, all that is really necessary >>> is that you make your task the highest priority, period. >>> >>> I am happy to see that others have caught on to this excellent method. >[...] >>> -Matt > >I hate to do this, but what happens if your hard disk controller employs >delayed writes? (Some do.) If you are the highest priority task and the >OS returns control to you before a write occurs, then when does it happen? >Probably the next time you WAIT(), but that might be a long time. > >I'd like to know more on how the machine functions when your task is CPU >intensive and running at maximum priority. > >-- >Jason L. Tibbitts III | Moderator: comp.sys.amiga.reviews Yes, something like that could indeed happen in which case the operation gets delayed, possibly for a long time. I think it's a non-problem in terms of writes, though, a game doesn't normally need to write to disk during critical action, and when it is doing something like displaying the title screen or saving the game it can easily run at a normal priority. -Matt >"Blob Shop Programmers:| Send submissions to HONP9@menudo.uh.edu > Because We're Bored!" | Check comp.sys.amiga.reviews for submissions >Disclaimer: Opinions...| guide, disclaimers, etc. Fnord. -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA