Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-beacon!eru!kth.se!sunic!news.funet.fi!cc.tut.fi!cc.tut.fi!n67786 From: n67786@cc.tut.fi (Tero Nieminen) Newsgroups: comp.sys.mac.system Subject: Re: Preemption good, time-slicing bad (was Re: All about sys 7.0 ) Message-ID: Date: 2 Apr 91 14:19:09 GMT References: <1CE00001.bmpkbkz@tbomb.ice.com> <10227@hub.ucsb.edu> <1991Apr1.232302.6882@bronze.ucs.indiana.edu> Sender: n67786@cc.tut.fi (Tero Nieminen) Organization: Tampere Univ. of Technology, Finland. Lines: 99 In-Reply-To: tagreen@bronze.ucs.indiana.edu's message of 1 Apr 91 23:23:02 GMT In article <1991Apr1.232302.6882@bronze.ucs.indiana.edu> tagreen@bronze.ucs.indiana.edu (Todd A. Green) writes: I concur that right now there is no way for the user to give a program priority, but since when you call WaitNextEvent() you pass as one of its arguments a value that will tell your app how many ticks you are willing to give up before gaining the cpu back, I don't see why it would be that hard to implement this. I'm still relatively new at programming the Mac, but wouldn't this seem like a logical solution: You can declare your sleep time parameter to be a variable and then give the user a way of changing the amount of ticks that s/he wants the application to give up. (At least it's one that I've put into all my (whopping 4 ;) ) programs I've written. This could be in the form of a slidebar in a dialog box, a simple pull down menu item, or whathaveyou. Now wouldn't it be even better (IMO) if Apple where to implement this at the system level, say perhaps when you called "About the Finder" (or it could have it's own dialog box) instead of just giving you the apps that are running, their memory usage etc., you also had an option to change the amount of ticks the apps would give up. This way there would be a common interface for developers and users alike. A macintosh version of the "nice" command in Un*x. Only partly and unfortunately in an improper order. Of cource programs that are idling can call it with a big enough value never to be called again due to this timing coming to end. But in the case of an active process it is a lot uglier to decide for how long this particular process thould be given cpu time before it return to give time to other processes, which is most probably what you'd want anyway in order to prevent sluggishness. Now it's often not at all that easy to estimate how long a process is going to take to finnish should you call it periodically in the spoken process. Think for example an iterative process. Are you going to call WaitNextEvent every time (no waste of time due to relatively slow context swithing of the MF) or do you maintain a separate time-slice-variable that when it reaches certain value you reset it and call WaitNextEvent (this might be more efficient). You might also want to rotate some cursor or something during theese times. Also this kind of fiddling would be needed with recursive proceduress, allbeit one more level of programming is needed to hold this time-slice-variable. Also it makes general purpose libraries somewhat annoying to write, since you have to insert this kind of callback in every library procedure that might consume enough time to cause sluggishness. If MF instead had preemptive multitasking with time slicing all this hassle would be taken care by the scheduler of the OS. But it's not at all that easy to provide such scheduler into MF since the Mac OS wasn't designed that way and it brings a lot of grief to make it work. When all this was combined with a clever prioritizing scheme that would give interactive processes relatively high priority to produce faster responses to user actions, what more could we hope for. But as the Mac OS being what it is, this might prove to be more than difficult to achieve, which is sad. I guess the original designers of the Macintosh didn't forsee this kind of need and so didn't prepare for it, so that now apple has to be making all kinds of excuses why they are not making it. The designers of the Amiga did see this, but their implementation is still far from the capabilities of a unix system, which is good refrence point. Also on another side note, someone said earlier that all programs that are running in the background get the same amount of time, yet no one contested it. This is not true as I understand it, and would really like to be corrected if I am wrong. (Probably should go home and read IM again...but I do have that Portuguese paper due *sigh* ). It's my understanding that apps in the "background" get a time slice and then perform whatever routines they want and then release the cpu again. Thus if I check for context switching (via app4 event right?) and see that I've been switched out to the background I can be a "nice" programmer and change my sleep parameter to give up say 10 ticks before trying to regain the cpu, whereas when I get switched back into the foreground (and yes I know this language is vague and there are different kinds of context switches, but I hope I've made myself clear) then I can use more cpu time setting my sleep value to 0L, since I am the application that would probably need the most attention. Of course this depends on exactly what type of application you are writing etc...but these are just general thoughts. My main ? is that even though you've been switched out that does not mean that all of a sudden you get the same amount of time as all other apps correct? But since the mac is a cooperative multitasking system no matter how small you set the time slice you won't gain time before other processes have given up their right to take what they want. If, on the other hand, this time slice had a stronger impact on processes currently running the OS would interrupt the time hogger and give a time slice to other processes too. But there it goes. The dreaded "interrupt time". Currently it would not be possible to just interrupt a process and give time to others since the running process might be in a middle of a heap relocating process during which several activities by programs are strictly forbidden. We would need away to eiher prevent time slice interrupts during such moments (which probably could be cludged into the Mac OS) or redesign the memory allocator to allow such interrupts to occur (you know some process might be in a middle of allocating a HUGE memory block, which we don't want to wait to finnish). But all in all this would make just more mess into the OS. In practice it would need to be redesigned in a clean way, which is why it hasn't been done yet. Eventually, one way or the other, it will. -- Tero Nieminen Tampere University of Technology n67786@cc.tut.fi Tampere, Finland, Europe