Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!usc!apple!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga.advocacy Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...) Message-ID: <1991Jan16.020617.10646@zorch.SF-Bay.ORG> Date: 16 Jan 91 02:06:17 GMT References: <7504@sugar.hackercorp.com> <7523@sugar.hackercorp.com> Organization: SF-Bay Public-Access Unix Lines: 49 burley@geech.ai.mit.edu (Craig Burley) writes: > 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 > aren't inherently resource intensive (like just holding a mouse button > down without moving the mouse), does true multitasking keep working? > My guess would be yes, it does. peter@sugar.hackercorp.com (Peter da Silva) writes: > Multitasking continues, however that screen is locked (any task doing > output to that screen is deferred) until you release that task. Yes, But be really careful to differentiate "task" from "program"; it is the actual modification of screen pixels that is locked (and probably only if you actually do it through the nice Intuition interfaces; scribbling directly on the bitmaps yourself doesn't look lockable, though you may then be scribbling on the menu rather than the (blitted away?) area "under" it); the rest of the program's tasks go right on executing. I tried the trick of listing /etc/termcap on my terminal emulator, then grabbing a menu on the same screen; the listing stopped being drawn, just as you say, but the characters kept being received through the modem, and the display work stacked up; when I let the menu go, the arrived text was blasted to the screen at the fastfonts inherent maybe 40Kbytes per second rate, rather than the modem's 120 bytes per second rate. > Programs that don't output to that screen (either they have their own > screen or they're smart and spawned a task for display update) aren't > affected. And parts of programs that aren't involved with screen changes keep right on going. From the behavior I saw, I'd guess my emulator was sending text display requests to Intuition as messages, and Intuition was stacking the messages until the menu was released, then doing them all as fast as possible. I'd guess that means I could stack up messages until I ran out of memory. With /etc/termcap and the overhead of a message, even 9 Megabytes may be too little room to hold open that menu "forever". > The only way to stop context switching is to call Forbid() or > Disable() and sit in a busy-wait, or otherwise do something REAL > stupid. Programs that do that don't tend to get good reviews in Amiga > magazines. And get toasted a bit in the c.s.a.* arena, too. ;-) Kent, the man from xanth.