Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!lll-winken!taco!hobbes.catt.ncsu.edu!kdarling From: kdarling@hobbes.catt.ncsu.edu (Kevin Darling) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Some WB2.0 Peeves Message-ID: <1991Jun28.095803.15224@ncsu.edu> Date: 28 Jun 91 09:58:03 GMT References: <1991Jun25.112729.27772@mintaka.lcs.mit.edu> <14296@goofy.Apple.COM> <1991Jun28.025117.23230@ncsu.edu> <1991Jun28.065023.1581@mintaka.lcs.mit.edu> Sender: news@ncsu.edu (USENET News System) Organization: North Carolina State University Lines: 100 rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >>My own opinion: a multitasking machine should _always_ multitask, not flake >>out simply because of some weak "cpu-speed" or "GUI speed/need" cop out. >>Performance issues? Make me laugh. _Any_ speed is faster than being STOPPED! > > Kevin, you're being silly. The Amiga doesn't stop when you pull down > a menu, only rendering is blocked on the current screen. The process(es) rendering are blocked as long as the user fiddles around; so whooops... out goes any benefits of preemptive multitasking for them. > Let's say a program needs to get at a shared system structure and it > obtains a semaphore lock on that structure, is the machine flaking out when > another task is put to sleep that also tries to access the same structure > and can't get the semaphore it wants? If the structure you're talking about is a large chunk of shared memory, then it would be wasteful to lock ALL of it out to access just a tiny piece. In a similar fashion, there's no need to lock down an entire screen just so some tiny window movement outlines (or even a menu) can be displayed. Unless, of course, you're taking the quick and dirty way out :-) > Semaphore locks are better than _nothing_ considering in the past, > programs have Forbid() (or even worse Disable()) to access system > structures that may change. Forbid() blocks all tasks, semaphore locks > only block tasks that want that semaphore. The rest run free. We're in full agreement there. > So let's assume you just dragged a window. You are blocking a task > from rendering to _that one screen_ for about 1 second. Hardly > a performance loss. Now we're not :-) You dare to mock other machines which block their cpu during disk accesses and so forth, and yet defend this Amiga behavior?? [Gomer Pyle voice as only a TarHeel can] For shame, for shame, for shame! > Perhaps you don't understand the full implications of making menus > into layers. [short list deleted] [wry voice] Yes, I guess since I implemented overlapping windows in a few hundred bytes on a 6809 multitasking machine, I "don't understand". Hey, I can't help it if the Amiga layers library is slow and cumbersome. You _did_ have a good point about possible 68K memory fragmentation tho. Fortunately, the CoCo-3 uses an MMU. No such thing as memory frag on it! But I have to contend with such on the simpler 68K OS-9 systems . > Something like Imagine which has a seperate task for rendering won't even > be affected. Multi-threaded apps in general won't be affected. True. How many apps work that way, tho? Better be ALL of them, or my point still stands :-) >>Under ver3.0 of OS-9 for the 6809-based CoCo-3, neither window moves/resizes >>nor menu pulldowns stop any of the other windows from continuing output. >>(Altho the menus were easy: they are contained per window, not at the top :) > > I bet menu rendering wasn't as quick as the Amiga. Now who's being "silly"? Except for any diffs because of the cpus/etc, there's no reason for menus to be drawn slower, or react slower than people. >>Furthermore, you can even move a window to _any_ other open gfx screen! >>(just "pick" it up, click around on the next-screen mouse button, and click >>the window back down wherever). Try that, y'all! ha! HA! HAHA! HAHAHAHA! > > This is something I'd like to see on the Amiga. So would I. It's way cool. Actually made the idea of windows on a multiple screen machine make _sense_ to me (I agree that multiple screens as the Amiga and CoCo have, are far easier to use & more powerful than Mac windows). BTW, since you brought up some related problems, here's what I did: when you click on the part of the window to move it, the outline box shows up as normal. Then if you hit the other mouse button (or the keyboard) and cycle thru the screens, the system simply skipped over any screen types which were bogus (on the coco: text or custom screens, or too small a space). So any screen the outline went to, was guaranteed as a good destination. > I can't tell whether you were joking in this post or not Kevin, but Well, my tone was meant to be jocular, even if the subject wasn't :-) > [....] Aha! I finally discovered why the Mac doesn't > have preemptive multitasking. I bet lots of Mac apps have free > access to system globals, and none of them use locking/Forbid() type > mechanisms so adding preemptive multitasking to the Mac might break > some programs. [...] Yah, that's the killer on most OS's which started out as singletasking. And to prevent breakage, Amigas can't use MMUs. They're both a mess :-] Anyway: is keeping full multitasking worth the possibly slower background rendering? My answer was/is emphatically Yes. Otherwise you could stretch and stretch and decide that well, locking for a minute might be okay, too. None of that fits in with the superiority of preemptive multitasking tho, eh? regards - kevin Apologies for length, too.