Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!gatech!mcnc!ncsuvx!news From: kdarling@hobbes.ncsu.edu (Kevin Darling) Newsgroups: comp.sys.amiga.advocacy Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...) Message-ID: <1991Jan17.203918.7882@ncsuvx.ncsu.edu> Date: 17 Jan 91 20:39:18 GMT References: <17210@cbmvax.commodore. <7504@sugar.hackercorp.com> <10404.tnews@templar.actrix.gen.nz> Sender: news@ncsuvx.ncsu.edu (USENET News System) Organization: NCSU Computing Center Lines: 22 burley@geech.ai.mit.edu (Craig Burley) writes about multitasking: > Anyone care to post whether this kind of scenario works on the Amiga? I.e. > when holding a menu down, or doing other purely user-interface things that jbickers@templar.actrix.gen.nz (John Bickers) (and others) reply: > If you do something that requires locking the display a task is using > (menus, resizing, moving the window, etc), the task may be stopped > until you release the mouse button (there are different ways of > writing to a display - some care about locked displays, some don't). Perhaps this could/should be changed. It is always abhorent to me to have a supposedly preemptive system have any processes stopped or held due to fairly common (and possibly lengthy) user interactions. Resize/move rubberband lines can be flicked on/off screen during an interrupt, allowing any graphics output to otherwise continue on that screen. I've done a windowing system like this; it works like a charm. Menus are harder, but if programs use device-independent gfx calls (that is, they don't directly diddle screen memory), then this problem goes away also. - kevin