Path: utzoo!attcan!uunet!cs.utexas.edu!rice!news.rice.edu!pete From: pete@titan.rice.edu (Pete Keleher) Newsgroups: comp.sys.mac.programmer Subject: Re: Two suggestions for THINK C Message-ID: Date: 2 Aug 90 15:45:54 GMT References: <1990Aug1.220231.18581@ucselx.sdsu.edu> <1990Aug2.065801.5767@d.cs.okstate.edu> <39FN4Y@cs.swarthmore.edu> Sender: news@rice.edu (Priestess to the News Gods) Organization: Whatsamatta U Lines: 28 In-Reply-To: jackiw@cs.swarthmore.edu's message of 2 Aug 90 13:41:16 GMT jackiw@cs.swarthmore.edu (Nick Jackiw) writes: > going to come up with user-based OS task scheduling soon, I frequently > dream about my more sophisticated and time-consuming utilities (e. g. my > compilers) allowing me at least to schedule their individual behavior. > Some sort of meter in the Compile Options dialog could represent a percent > of CPU time I desire to allocate to the compilation. It would default to > 100--never switch out, never call WNE. (This is what it does now, I > assume--it checks for cmd-. by consulting the keymap, not the event queue.) Although I haven't actually checked w/ MacNosy, I would guess that it does use the event queue, not the keymap. Command equivalents that are typed during compilation are lost, although as soon as linking starts, keyboard events can be entered which take you though the debugger and quite far into the application that you are working on. Many of the comments in this thread have dealt with how the compiler can decide that it has had enough cpu so that it can let the foreground processcrank for a bit time. In reality, the problem is that there are many applications out there that still don't use WaitNextEvent, which would prevent the compiler (the background applicataion) from getting any time at all. -- ============================================================================= Pete Keleher pete@titan.rice.edu The Alpha Editor is available from 'rascal.ics.utexas.edu' (128.83.144.1). =============================================================================