Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!rpi!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!peter From: peter@sugar.hackercorp.com (Peter da Silva) Newsgroups: comp.sys.amiga.advocacy Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...) Message-ID: <7609@sugar.hackercorp.com> Date: 26 Jan 91 02:35:07 GMT References: <1991Jan18.231330.16290@Neon.Stanford.EDU> <7553@sugar.hackercorp.com> <1991Jan23.213736.28220@Neon.Stanford.EDU> Organization: Sugar Land Unix - Houston Lines: 25 In article <1991Jan23.213736.28220@Neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan J Torrie) writes: > You say some programs do use input-handlers... does this mean they > multi-thread themselves, spinning off an input handler task, and then > communicate between the main program and the input handler task? Yes. What they usually do is create a message port, and then spawn off a task to handle computations. This task immediately waits on the message port until you need to crunch. The user-interface task can then sit there handling the user's requests. > From the discussion above, it seems that the input.device task will > handle the mouse down immediately (because it's running at such a high > priority). But normally, the code to regenerate the window's view > (what I call an Update event) is located in the main word processor > task. A word processor would probably not be split up this way, because they don't tend to be compute bound. This would be more like a spreadsheet. Also, the display would be handled by the user-interface task. The compute task just updates internal tables... the display selects the portions of those tables the user wants to see and presents them. -- Peter da Silva. `-_-' .