csnjr@its63b.ed.ac.uk (Nick Rothwell) (03/17/88)
From article <3268@zeus.TEK.COM>, by bobr@zeus.TEK.COM (Robert Reed): > This is the crux of the issue. In your narrowed view of multitasking, IPC > requirements may exclude such systems as Multifinder. Yet, Multifinder fits > broader views of multitasking which rely only on the ability to share > resources among a set of simultaneously executing processes. Consider this a general posting rather than a response to Robert's comments in particular... Is the following a reason to prefer Multifinder's event-driven multitasking to "real" timesliced multitasking? If I'm running some sort of package which does real-time things, like timing events, and doing things at certain times, I presumably don't want the OS occasionally kicking in to attempt a re-scheduling, even if nothing else is runnable. At least with Multifinder's approach, if my time-critical application has the machine, it keeps it until it's finished. In fact, timing things on input is probably OK as long as you have kernel routines to timestamp stuff. But output still seems like a problem. The application which came to mind this morning: MIDI sequencing software. If my sequencer is going flat out, I'm playing into it from my keyboard, and it has to get notes and so on out to the noise boxes within milliseconds. When it's stopped (and awaiting mouse input), then I can "swap" it out and look at something else, but when it's going, I don't want anything else to trip it up. Here's a technical question, out of curiosity - I presume the MacOs's GetNextEvent (or whatever) is a "let me sleep until mouse or window or keyboard event" kind of call. So: how does one extend the set of required events (for example: let me sleep until mouse or window or keyboard or character at the modem port)? Is the set of event types infinitely extensible? Or are there only ever going to be a fixed number? > Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick%lfcs.ed.ac.uk@nss.cs.ucl.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ...while the builders of the cages sleep with bullets, bars and stone, they do not see your road to freedom that you build with flesh and bone.
ali@polya.STANFORD.EDU (Ali Ozer) (03/19/88)
In article <1092@its63b.ed.ac.uk> nick%ed.lfcs@uk.ac.ucl.cs.nss writes: > If I'm running some sort of package which does real-time things, >like timing events, and doing things at certain times, I presumably >don't want the OS occasionally kicking in to attempt a re-scheduling, >even if nothing else is runnable. At least with Multifinder's >approach, if my time-critical application has the machine, it keeps it >until it's finished. On a single-user machine, you should have a means with which you can stop multitasking. As Matt mentioned in an earlier message, the Amiga for instance, provides the Forbid()/Permit() pair (which simply tells the scheduler not to schedule another task) and the Disable()/Enable() pair (which prevents the scheduler from kicking in at all). These are implemented very efficiently, are nestable, and they will be suspended (temporarily) if your task happens to call Wait() or somehow falls asleep (otherwise what do you get?! 8-). Of course you normally wouldn't use these (even if you were operating at MIDI speeds), but sometimes it's a good idea (for instance, if you are examining the system list of tasks, and don't want it to change and leave you with a dangling pointer!). Ali Ozer, ali@polya.stanford.edu
denbeste@bgsuvax.UUCP (William C. DenBesten) (03/21/88)
From article <1092@its63b.ed.ac.uk>, by csnjr@its63b.ed.ac.uk (Nick Rothwell): > Here's a technical question, out of curiosity - I presume the > MacOs's GetNextEvent (or whatever) is a "let me sleep until mouse or > window or keyboard event" kind of call. Almost, but not quite. If there is nothing to do GetNextEvent returns so that an application can do its idle stuff. There is another call, WaitNextEvent that will not return unless there IS something interesting. > So: how does one extend the > set of required events (for example: let me sleep until mouse or > window or keyboard or character at the modem port)? Is the set of > event types infinitely extensible? Or are there only ever going to be > a fixed number? The way things are currently set up, there is a limit of 15 types of events. The things that are reported as events are: 1,2 mouse button down or up 3,4,5 keypressed, released or autorepeated 6,8 window needs updated, highlited or unhighlited 7,10,11 disk, or other driver (such as serial) needs attention 14,15 program is being swapped in our out. 12,13 any two things that the application cares to define. Wait next event will also return after a specified time has elapsed or the mouse enters (leaves?) a specified region. GetNextEvent returns with NullEvent if there is nothing happening. -- William C. DenBesten | denbeste@bgsu.edu Dept of Computer Science | CSNET denbeste%andy.bgsu.edu@relay.cs.net Bowling Green State University | UUCP ...!cbosgd!osu-cis!bgsuvax!denbeste Bowling Green, OH 43403-0214 |