jtn@zodiac.ADS.COM (John Nelson) (11/14/89)
Hi all. Well thanks everybody for the responses concerning my question about parameter blocks and trying to find out whether a file is a folder or a file. I just wrote some functions to access the parameter blocks. Now another question has come up. We're intersted in writing a system that is composed of many processes all talking to each other and passing data back and forth. Even under MultiFinder I haven't seen a lot of this done so I conclude that it is an ineffecient and difficult to program sort of thing to do. Is multitasking difficult to do on the Mac? Is it effecient? Creating seperate processes would make the architecture of our system nice and clean, but if it's going to load the machine needlessly then we don't want it. Can anyone provide pointers to technical notes or other references concerning MultiFinde and MultiTasking (and XCMDS too I guess). Thanks! -- John T. Nelson UUCP: sun!sundc!potomac!jtn Advanced Decision Systems Internet: jtn@potomac.ads.com 1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (11/15/89)
In article <9775@zodiac.ADS.COM> jtn@zodiac.ADS.COM (John Nelson) writes: >Now another question has come up. We're intersted in writing a system >that is composed of many processes all talking to each other and >passing data back and forth. Even under MultiFinder I haven't seen a... > >Is multitasking difficult to do on the Mac? Is it effecient? Gawd! The true vs. fake multitasking wars are about to heat up again. Anyway, if you can't wait for Apple's implementation of InterApplication Communication (System 7), there was an IAC driver article in some MacTutors within the last year and a half or so. ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
tjf@lanl.gov (Tom J Farish) (11/18/89)
Hi...No flames, please. The Amiga computer from commodore runs 680X0 with 6888X support with multitasking. It is a VERY capable machine with the OS in software and video/graphics in firmware. I've heard that multitasking has been dropped from system 7 for the Mac...Why?
lsr@Apple.COM (Larry Rosenstein) (11/18/89)
In article <36687@lanl.gov> tjf@lanl.gov (Tom J Farish) writes: > I've heard that multitasking has been dropped from system 7 for the > Mac...Why? Multitasking hasn't be dropped from System 7.0; I don't know where you might have heard this. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
macgyver@banana.cis.ohio-state.edu (wilson m liaw) (11/18/89)
In article <5267@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >In article <36687@lanl.gov> tjf@lanl.gov (Tom J Farish) writes: > >> I've heard that multitasking has been dropped from system 7 for the >> Mac...Why? > >Multitasking hasn't be dropped from System 7.0; I don't know where you >might have heard this. Are we talking about the same type of Multitasking here? I think Tom was talking about true multitasking.( As in unix.) While the multitasking in System 7.0 is like the current MultiFinder. Mac -=- Wilson "Mac" Liaw |Don't fall in love, it's too complicated. Internet:macgyver@cis.ohio-state.edu | - Molly Ringwald =============================================================================== Disclaimer:Nobody knows what I am talking about, including myself.
tecot@Apple.COM (Ed Tecot) (11/18/89)
In article <74117@tut.cis.ohio-state.edu> wilson m liaw <macgyver@cis.ohio-state.edu> writes: >In article <5267@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >>In article <36687@lanl.gov> tjf@lanl.gov (Tom J Farish) writes: >> >>> I've heard that multitasking has been dropped from system 7 for the >>> Mac...Why? >> >>Multitasking hasn't be dropped from System 7.0; I don't know where you >>might have heard this. > > Are we talking about the same type of Multitasking here? I think Tom >was talking about true multitasking.( As in unix.) While the multitasking in >System 7.0 is like the current MultiFinder. Oh no; I see a storm coming. In the interest of saving hundreds, perhaps thousands of dollars, please refrain from arguing why MultiFinder is or is not "true multitasking". (Personally, I beleive that "true multitasking" is akin to "standard Unix"; put please don't waste net bandwidth arguing that point either.) _emt
tjf@lanl.gov (Tom J Farish) (11/19/89)
> >Multitasking hasn't be dropped from System 7.0; I don't know where you > >might have heard this. > > Are we talking about the same type of Multitasking here? I think Tom > was talking about true multitasking.( As in unix.) While the multitasking in > System 7.0 is like the current MultiFinder. > > Mac > right...There will be no true multitaking ala Unix in System seven according to BYTE (2 most recent issues?). Enhanced Multifinder is more like what System 7 can do. What a shame... Now, how 'bout that virtual memory? flame on Of course (ahem) one could still pick up a MacII Clone with 8 megs, System 8(!), true multitaksking, virtual memory for about $3k.... (humble amiga)... flame off I use both a Mac II and Amiga 2500 at work and have really gotten hooked on true multitasking. Such an addition to Mac system 7 (or 8) would make that machine MUCH more useful for us type A personalities who like to have 3 or 4 things going at once. I like the Mac ii, and I must use Excel, etc as eveyone else does here at the lab ;^), but if I could get along only with the amiga, I probably would. My previous multitaking system was a MacII AND MacPlus on one desk... Comments appreciated; flames ignored....
tim@hoptoad.uucp (Tim Maroney) (11/20/89)
In article <36687@lanl.gov> tjf@lanl.gov (Tom J Farish) writes: > I've heard that multitasking has been dropped from system 7 for the > Mac...Why? In article <5267@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >Multitasking hasn't be dropped from System 7.0; I don't know where you >might have heard this. In article <74117@tut.cis.ohio-state.edu> wilson m liaw <macgyver@cis.ohio-state.edu> writes: > Are we talking about the same type of Multitasking here? I think Tom >was talking about true multitasking.( As in unix.) While the multitasking in >System 7.0 is like the current MultiFinder. Oh no, not this argument again! I hope a few words can hold off a slew of messages debating the true meaning of multitasking. Multitasking means simply that a computer is capable of switching its operation between a set of independent or semi-independent "tasks", which take the form of separate pieces of compiled software. There are a number of types of multitasking, which may broadly be divided into synchronous and asynchronous. In synchronous multitasking, each piece of software must explicitly signal the scheduler that it is willing to give up control of the processor for a task switch to happen. This is the kind of multitasking currently implemented on the Mac; the signals that a task is willing to give up the processor are (for applications) GetNextEvent, WaitNextEvent, and SystemTask, and (for desk accessories) returning from a request call initiated by the operating system. The Mac has always had this capability with respect to desk accessories; MultiFinder added this capability with respect to applications. In asynchronous or time-sliced multitasking, the scheduler does not depend on signals from software that they are ready to give up the processor. instead, they are assumed to always be ready to give up execution, and they do so when the scheduler demands that they do so by saving their context and passing execution to another task, typically during a clock interrupt. The Mac does not have this capability, and I doubt that it will have it in System 7.0. Nor does it greatly suffer for the loss. Any Mac application that does not give up the processor for a long time is probably engaged in a processor-intensive task which would allow other tasks to run only very slowly, and which itself would run very slowly if it were being switched in and out. I think it is very far from correct to refer to only time-sliced multitasking as "true" multitasking, at least on a single-user computer. (It *is* important for multi-user systems, I admit.) Synchronous multitasking is true multitasking. (Nor is it true to say that UNIX by nature has this "true" multitasking. This is true of the overwhelming majority of UNIX systems, but I have read of some which used synchronous multitasking, context switching only when a program makes a system call [an implicit signal that the software is willing to give up control of the processor].) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Philosophy is the talk on a cereal box Religion is the smile on a dog" -- Edie Brickell, "What I Am"
d88-jwa@nada.kth.se (Jon Watte) (11/21/89)
In article <74117@tut.cis.ohio-state.edu> wilson m liaw <macgyver@cis.ohio-state.edu> writes: > Are we talking about the same type of Multitasking here? I think Tom >was talking about true multitasking.( As in unix.) While the multitasking in >System 7.0 is like the current MultiFinder. Oh, NOOO ! Not this "TRUE" multitasking war again ! I think we've all settled on the non-preemptive multitasking and the pre-emptive multitasking being equally transparent to the user, since most mac applications follow the MultiFinder programmers guidelines. As long as the machine runs several applications simultaneously, I don't think this is much to discuss, actually, so why don't we move on to more interesting things, like... PROTECTED MEMORY ! (Which, by the way, is a requirement for "That other kind of" multitasking 8) The sun always shines in my mac h+ -- This .signature is longer than 4 lines. If you'd like to see it in whole, please send a note to me. I'm h+@nada.kth.se and also h+@proxxi.se 8')
tim@hoptoad.uucp (Tim Maroney) (11/22/89)
In article <2352@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes: >As long as the machine runs several applications simultaneously, >I don't think this is much to discuss, actually, so why don't we >move on to more interesting things, like... PROTECTED MEMORY ! >(Which, by the way, is a requirement for "That other kind of" >multitasking 8) Despite the smiley, this point deserves answering. Protected memory is not a requirement for asynchronous (or time-sliced or pre-emptive) multitasking. It's very nice to have with *any* kind of multitasking, or even with single-tasking systems with a division between OS and user task, but it's by no means necessary. It's just a good thing for system reliability, particularly on development systems where code in progress is very likely to sometimes step all over the OS or other tasks. Unfortunately, Apple doesn't think it's important, despite near-unanimity in the developer community to the contrary. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "When errors are found in old research, the relevant theories are re-examined. When facts contradict theory, theory gets dumped. Is that why the NLP people are unwilling to research their facts?" -- Jerry Hollombe on sci.psychology
chewy@apple.com (Paul Snively) (11/22/89)
In article <9035@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > Protected memory is > not a requirement for asynchronous (or time-sliced or pre-emptive) > multitasking. It's very nice to have with *any* kind of multitasking, > or even with single-tasking systems with a division between OS and user > task, but it's by no means necessary. It's just a good thing for > system reliability, particularly on development systems where code in > progress is very likely to sometimes step all over the OS or other > tasks. Unfortunately, Apple doesn't think it's important, despite > near-unanimity in the developer community to the contrary. > -- > Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com I'm curious, Tim, as to precisely when any entity called Apple revealed to you that it doesn't think that protected memory is important. I'd wager large sums of money that what you REALLY mean is "MultiFinder/MacOS doesn't support protected memory, therefore whoever is ultimately responsible for the engineers who wrote MultiFinder/MacOS must not think that protected memory is important." My personal opinion is that there was no good way to implement protected memory for the MacOS on the few machines that we have that are even guaranteed to have a PMMU chip, and that while we were able to hack multitasking comparatively well, we would have created far more problems with trying to implement protected memory on top of the current OS. It seems like a lot of what's being asked for will have to wait for a brand-spanking new OS. That wouldn't be a bad thing (also in my opinion) but neither can I make any promises. Sorry. __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________
lemke@radius.UUCP (Steve Lemke) (11/22/89)
In article <36755@lanl.gov> tjf@lanl.gov (Tom J Farish) writes: }right...There will be no true multitaking ala Unix in System seven }according to BYTE (2 most recent issues?). Enhanced Multifinder is }more like what System 7 can do. What a shame... } [...] }I use both a Mac II and Amiga 2500 at work and have really gotten }hooked on true multitasking. Such an addition to Mac system 7 (or }8) would make that machine MUCH more useful for us type A personalities }who like to have 3 or 4 things going at once. } }Comments appreciated; flames ignored.... OK, in that case... I'm not trying to start a net.bandwith-wasting flame/discussion war here, but I'm curious: What is it that you do on the Amiga (3 or 4 things at once) that truly requires "True Multitasking"(TM) and therefore is impossible on the Mac? I use MultiFinder all day long (alas, with only 2.5mb, though I have 5mb at home) and constantly run several things at once, such as a database, email, word processor, NCSA Telnet and/or AppleLink, MacDraw, etc. My only problem is running out of RAM since I only have 2.5mb. -- ----- Steve Lemke, Engineering Quality Assurance, Radius Inc., San Jose ----- ----- Reply to: radius!lemke@apple.com (Coming soon: radius.com ...) ----- ----- AppleLink: Radius.QA; GEnie: S.Lemke; Compu$erve: 73627,570 -----
jwright@atanasoff.cs.iastate.edu (Jim Wright) (11/23/89)
radius!lemke@apple.com writes: | What is it that you do on the Amiga (3 or 4 things at once) that truly | requires "True Multitasking"(TM) and therefore is impossible on the Mac? OK, I'm sitting here with a 4 megabyte file to download. *PERFECT* use for multi-tasking. Thank god for multifinder. Fire it up, start the download. All's going well. Leave. Time passes. Return. Let's see how things are going. Switch over to another program. Browse around. Open up a menu from menu bar. Hmmm... what do I want to do? Look around for a bit. Make a selection. Check in on the download. WHAT!!!! ABORTED!!! Oh &^@$%^&%#@ great. The entire computer comes to a screeching halt when you're in a menu. What other kludges are lurking in there? I WANT REAL MULTITASKING. Multifinder is better than MSDOS, but not much. Followup to alt.dev.null. There's not much to do about this without a radical change to the Mac OS. -- Jim Wright jwright@atanasoff.cs.iastate.edu
lippin@spam.berkeley.edu (The Apathist) (11/23/89)
Recently jwright@atanasoff.cs.iastate.edu (Jim Wright) wrote: >OK, I'm sitting here with a 4 megabyte file to download. *PERFECT* use >for multi-tasking. Thank god for multifinder. Fire it up, start the >download. All's going well. Leave. Time passes. Return. Let's see >how things are going. Switch over to another program. Browse around. >Open up a menu from menu bar. [...] >There's not much to do about this without a radical change to the Mac OS. How about fixing MenuSelect (and other mouse following routines) to call SystemTask? That way, a terminal program, or anything else that runs into a critical need for non-interrupt time every 20 seconds or so can install a driver to get some. (Using EventAvail or WaitNextEvent won't work here, because they may not return for a month, and so it becomes painful to use menus. But SystemTask is currently pretty fast.) That's hardly a radical change to the OS; it is a bit more work for the writers of downloading programs. A better idea, IMHO, would be a separate manager for tasks which are quick, can't happen at interrupt time, and need to be called periodically. This would avoid overloading the already schizophrenic device manager, and so give a call that would return faster than SystemTask. It could also provide other services, such as a way to warn the background tasks when a program is going to seize the processor. >Followup to alt.dev.null. My, aren't we open minded today! --Tom Lippincott lippin@math.berkeley.edu "Do not meddle in the affairs of wizards, for they are subtle and quick to anger." --J.R.R. Tolkien
gft_robert@gsbacd.uchicago.edu (11/23/89)
In article <2008@atanasoff.cs.iastate.edu>, jwright@atanasoff.cs.iastate.edu (Jim Wright) writes... >radius!lemke@apple.com writes: >| What is it that you do on the Amiga (3 or 4 things at once) that truly >| requires "True Multitasking"(TM) and therefore is impossible on the Mac? > [starts download in background] >Open up a menu from menu bar. Hmmm... what do I want to do? Look around >for a bit. Make a selection. Check in on the download. WHAT!!!! >ABORTED!!! Oh &^@$%^&%#@ great. The entire computer comes to a screeching Sounds like it's your comm program, not the Mac OS. I've never had any problems of that nature when downloading (using Versaterm). I can choose menus, play games, etc. Pretty good multitasking, as far as I'm concerned. Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
tim@hoptoad.uucp (Tim Maroney) (11/24/89)
In article <2008@atanasoff.cs.iastate.edu> jwright@atanasoff.cs.iastate.edu (Jim Wright) writes: >OK, I'm sitting here with a 4 megabyte file to download. *PERFECT* use >for multi-tasking. Thank god for multifinder. Fire it up, start the >download. All's going well. Leave. Time passes. Return. Let's see >how things are going. Switch over to another program. Browse around. >Open up a menu from menu bar. Hmmm... what do I want to do? Look around >for a bit. Make a selection. Check in on the download. WHAT!!!! >ABORTED!!! Oh &^@$%^&%#@ great. The entire computer comes to a screeching >halt when you're in a menu. This is just an implementation problem; it's not some kind of theoretical limit to non-time-sliced multitasking. Currently, some user interface elements don't pass idle time to background applications when they should. These include menu tracking and control tracking. These are not intrinsic problems with the idea of synchronous multi-tasking; Apple just didn't realize that the routines Mouse and StillDown could be taken as implicit signals allowing a context switch. Hopefully, they will in future systems. >I WANT REAL MULTITASKING. Multifinder is better than MSDOS, but not much. > >Followup to alt.dev.null. There's not much to do about this without a >radical change to the Mac OS. Wrong. On the other hand, your point is not completely without merit. If you start an upload and then go into StuffIt to extract information from the file you just downloaded, StuffIt will refuse to give any time to the rest of the system until it completes, and your upload will time out. This is more of a problem, and it *is* an intrinsic problem that can only be solved with time-sliced multitasking. So you are partially correct; there are in fact some things that really do require time-slicing; but I think "not much better than MSDOS" is a huge exaggeration. And I've already dealt with the problems with calling only time-slicing "real multitasking". -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "I don't know that atheists should be considered citizens, nor should they be considered patriots. This is one nation under God." -- George Bush in FREE INQUIRY magazine, Fall 1988
tim@hoptoad.uucp (Tim Maroney) (11/24/89)
In article <6391@tank.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: >Sounds like it's your comm program, not the Mac OS. I've never had any >problems of that nature when downloading (using Versaterm). I can choose >menus, play games, etc. Pretty good multitasking, as far as I'm concerned. I wonder how they do that. Can anyone provide any information? My first thought was to schedule your file transfer protocol off the vertical retrace manager, but your tasks don't get called when you're switched out. Perhaps there's a loophole with the Time Manager that allows that, but the Time Manager is broken in a number of OS releases and really can't be relied on. You can't patch traps to do it because the patches only apply to your own application. Hmm. You could always install your own clock interrupts or something similarly awful, but forget compatibility! Perhaps installing a driver in an empty unit table slot would work, but I doubt drivers get any time when applications don't. Maybe if the driver installs the retrace routine, it will get called in any context? This is a very intriguing issue, and any answers would be appreciated. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "This signature is not to be quoted." -- Erland Sommarskog
jeremyr@cs.qmc.ac.uk (Jeremy Roussak) (11/25/89)
In article <9071@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >If you start an upload and then go into StuffIt to extract information >from the file you just downloaded, StuffIt will refuse to give any time >to the rest of the system until it completes, and your upload will time >out. This is more of a problem, and it *is* an intrinsic problem that >can only be solved with time-sliced multitasking. While not disagreeing with the very valid point you're making, Tim, you malign StuffIt. There's an option in the preferences dialogue (yes, I'm English) to tell StuffIt to allow time to background tasks. Jeremy Roussak
earleh@eleazar.dartmouth.edu (Earle R. Horton) (11/25/89)
In article <9072@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <6391@tank.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: >>Sounds like it's your comm program, not the Mac OS. I've never had any >>problems of that nature when downloading (using Versaterm). I can choose >>menus, play games, etc. Pretty good multitasking, as far as I'm concerned. > >I wonder how they do that. Can anyone provide any information? >[Discussion of how MultiFinder context switching breaks attempts to >schedule file transfer protocol.] I don't know, but won't an asynchronous read/write with an ioCompletion routine installed work? IO operation gets completed, then ioCompletion routine gets called, and file transfer can be restarted at that point. Make sure you get the correct A5 before storing your data! The protocols used by VersaTerm use handshaking on each packet. You don't get a new packet, in other words, until you acknowledge the last one. With these protocols, you can actually pause a fairly long time between times when you service the file transfer. I suspect that VersaTerm doesn't do anything special to make sure it gets time, but that you just never see it time out because you never push it that hard. ZTerm, on the other hand, uses zmodem, a streaming protocol. This means that it MUST service the file transfer periodically, or serial buffers will overflow, etc. Apparently, the author hasn't figured out this problem, because ZTerm will time out on you if you do too much other processing while it is transfering a file. Earle R. Horton
urlichs@smurf.ira.uka.de (Matthias Urlichs) (11/25/89)
In comp.sys.mac.programmer tim@hoptoad.UUCP (Tim Maroney) writes: < In article <6391@tank.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: < >Sounds like it's your comm program, not the Mac OS. I've never had any < >problems of that nature when downloading (using Versaterm). I can choose < >menus, play games, etc. Pretty good multitasking, as far as I'm concerned. < < I wonder how they do that. Can anyone provide any information? My < first thought was to schedule your file transfer protocol off the < vertical retrace manager, but your tasks don't get called when you're < switched out. [...] Well, I don't know how VersaTerm does it. I, however, simply would use completion routines. Store the data (using an async file manager call), send the acknowledge (async device manager call), get more data (another async device manager call, w/ the same completion routine). The only problem would be timing out if an error occurs. I'd use a time manager call -- for the hopefully few times a data error occurs, this may actually work. :-( Or they install their VBL task in the System heap, then it won't be deinstalled by MultiFinder... < "This signature is not to be quoted." -- Erland Sommarskog No? :-) -- Matthias Urlichs
tim@hoptoad.uucp (Tim Maroney) (11/25/89)
In article <17247@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: >I don't know, but won't an asynchronous read/write with an >ioCompletion routine installed work? IO operation gets completed, >then ioCompletion routine gets called, and file transfer can be >restarted at that point. Make sure you get the correct A5 before >storing your data! I thought that MultiFinder would refuse to context switch if the file or device system had any pending asynchronous requests. But maybe I'm thinking of an earlier incarnation. It's fairly painful to write a complete protocol scheduled from completion routines, but it can be done. >The protocols used by VersaTerm use handshaking on each packet. You >don't get a new packet, in other words, until you acknowledge the last >one. With these protocols, you can actually pause a fairly long time >between times when you service the file transfer. I suspect that >VersaTerm doesn't do anything special to make sure it gets time, but >that you just never see it time out because you never push it that >hard. Um, not with XMODEM. Most implementations will time out if they don't get an acknowledgement before the timeout period expires. Doesn't VersaTerm use XMODEM? -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "`Truth' never set anyone free. It is only *doubt* which will bring mental emancipation." -- Anton LaVey, quoted by Arthur Lyons, SATAN WANTS YOU
ech@cbnewsk.ATT.COM (ned.horvath) (11/25/89)
In article <6391@tank.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: >Sounds like it's your comm program, not the Mac OS. I've never had any >problems of that nature when downloading (using Versaterm). I can choose >menus, play games, etc. Pretty good multitasking, as far as I'm concerned. From article <9072@hoptoad.uucp>, by tim@hoptoad.uucp (Tim Maroney): > I wonder how they do that. Can anyone provide any information? My > first thought was to schedule your file transfer protocol off the > vertical retrace manager, but your tasks don't get called when you're > switched out... Unless you install the VBL task in the System heap. See TN 180 for a full discussion. =Ned Horvath=
ts@cup.portal.com (Tim W Smith) (11/25/89)
In article <6391@tank.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: >Sounds like it's your comm program, not the Mac OS. I've never had any >problems of that nature when downloading (using Versaterm). I can choose >menus, play games, etc. Pretty good multitasking, as far as I'm concerned. I think the original complaint was not that the person could not chose menus. The complaint was that the person could not take a long time waffling about in the menus before making a choice. Will Versaterm still work right in the background if you go to another application, pull down a menu, and just stay there with the meny pulled down? Tim Smith
ts@cup.portal.com (Tim W Smith) (11/25/89)
Tim Maroney writes: > I wonder how they do that. Can anyone provide any information? My > first thought was to schedule your file transfer protocol off the > vertical retrace manager, but your tasks don't get called when you're > switched out. Perhaps there's a loophole with the Time Manager that > allows that, but the Time Manager is broken in a number of OS releases > and really can't be relied on. You can't patch traps to do it because > the patches only apply to your own application. Hmm. You could always > install your own clock interrupts or something similarly awful, but Even if they manage to get something like this to work, there are still problems. At some point the file transfer protocol is going to have filled all the buffers it has available and is going to need to do some file I/O. Is it safe to do file I/O from an interrupt routine? I doubt it. Even if the File Manager can handle it, the SCSI Manager is not supposed to be used this way. > forget compatibility! Perhaps installing a driver in an empty unit > table slot would work, but I doubt drivers get any time when > applications don't. Maybe if the driver installs the retrace routine, > it will get called in any context? People who write drivers for SCSI Ethernet adaptors run into this sort of problem. If the driver sets dNeedTime to get run time to check the device for incomming packets, it hangs up when the application does a synchronous read call. AppleShare likes to do these, so if the driver is using this mechanism, it fails to work with AppleShare. A vertical retrace routine installed by the driver does appear to get called all the time. Of course, then it has the problem of using the SCSI Manager at interrupt time. The approach we took with the Dove FastNet SCSI driver was to use a vertical retrace routine, but to be very careful to try to avoid calling the SCSI Manager if there is any indication that something else ( e.g., a SCSI disk driver ) could be using the SCSI Manager at the moment. It seems to work OK. This problem also shows up with removable media SCSI disk drives. The driver needs to check the drive to see if the media has been inserted. The obvious way is to use dNeedTime. However, dNeedTime events do not get called during the "Please insert the disk named Spam" dialog, which is of course the most important place you need to recognize when a disk has been inserted! There are two approaches that driver writers use here. One is to have a vertical retrace task. This is what I tend to use. I use dNeedTime, but have a vertical retrace task too, and if the vertical retrace task sees that a couple of seconds have passed without dNeedTime events happening, it checks for a disk having been inserted. It makes the same sort of safety checks that I do with FastNet SCSI, so it should be safe. The other approach that is often used is to patch a trap. There is one trap, which I forget, that is called repeatedly while the "Please insert " dialog is up. The driver patches this trap and the patch code checks for the disk having been inserted before jumping to the original code. Tim Smith
jmunkki@kampi.hut.fi (Juri Munkki) (11/25/89)
In <1487@sequent.cs.qmc.ac.uk> jeremyr@cs.qmc.ac.uk (Jeremy Roussak) writes: >malign StuffIt. There's an option in the preferences dialogue (yes, >I'm English) to tell StuffIt to allow time to background tasks. Setting this option doesn't help much. It seems that Stuffit stops from time to time and uses that time to refresh a window and allow a few task switches to happen. It then happily crunches for a few seconds before pausing again. This isn't what it should do. The feature is useless because you can't really use a user interface that only reacts once every few seconds. Just try any paint program and you'll see what I mean. The only thing that it accomplishes is that some terminal programs might be able to go on transmitting files (although very slowly). Task switching should be allowed a lot more often. 5-10 times per second should be adequate. The task switching overhead will not be too high, unless you allow it to happen too often. 60 times per second is probably way too high. The way I would implement regular task switching is that I would keep a variable containing the next TickCount time at which the program should pause. When it's time to pause, I'd save the current TickCount and then call GetNextEvent to allow the task switch to happen. I would then handle any pending update and suspend/resume events that might be in the queue. After GetNextEvent returns, it has switched to the foreground task, if our task is in the background or it will have switched to one background task, if our task is in the frontmost layer. My routine should call TickCount again after the task switch. If too much time has elapsed in the GetNextEvent, I might consider changing the amount of time that I allow for my task. Since the cause is probably another background task that is munching away precious ticks, I would probably reduce the amount of time allowed for my task. This allows interactive processes to run faster. Usually you can just ignore that time spent in other tasks and just add a few ticks to the TickCount value that was obtained after calling GetNextEvent. This value then contains the amount of time that we have to spend doing our own stuff. Really nice programs allow the user to set that time. Some users might prefer to have really slow background processing, but extremely fast fast interactive processes, while some users might want just the opposite. Actually I don't have to do any of this in my terminal emulator. The program is currently totally MultiFinder unaware, but is also one of the most MultiFinder-friendly applications around*. Uploads and downloads do not have their own event loops. They just get regular calls from my main event loop, if they are active and their timeout value has elapsed or my serial management routines detect the they have received data. The time spent to calculate a checksum and read or write the data is minimal. The transfer window is updated every 1.5 seconds or when it receives an update event. (This means that for 1.5 seconds, one part of the window might contain different values than the other, but since the time is so short, it doesn't confuse users. If the regular update was every 25 seconds, some users might get confused by a window that has been partly updated with data that does not match the other half of the window.) Hmmm... I originally intended this article as a short comment on Stuffit task switching... How did it grow into this thing? I'd still say that Stuffit is a prime example of bad task switching. * Since my application is not MultiFinder-aware, you might say that it is not really MultiFinder-friendly. I'm just reporting on what it feels like to use the application. ATP might disagree. _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
urlichs@smurf.ira.uka.de (Matthias Urlichs) (11/26/89)
In comp.sys.mac.programmer tim@hoptoad.UUCP (Tim Maroney) writes: < In article <17247@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu < (Earle R. Horton) writes: < < I thought that MultiFinder would refuse to context switch if the file < or device system had any pending asynchronous requests. But maybe I'm < thinking of an earlier incarnation. It's fairly painful to write a < complete protocol scheduled from completion routines, but it can be < done. < MF currently checks if the file manager is busy. The device manager is not checked. So the file I/O requests occur on top of whatever application may be running at the moment. No problem (but check if you have enough room on the stack!) I would not describe running a protocol from completion routines as painful. It's more like a lot of typing. (I ought to know :-) -- my soon-to-be-released AppleShare-compatible server works that way.) -- Matthias Urlichs
earleh@eleazar.dartmouth.edu (Earle R. Horton) (11/26/89)
In article <9080@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <17247@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu >(Earle R. Horton) writes: >>I don't know, but won't an asynchronous read/write with an >>ioCompletion routine installed work? ... >I thought that MultiFinder would refuse to context switch if the file >or device system had any pending asynchronous requests. But maybe I'm >thinking of an earlier incarnation. It's fairly painful to write a >complete protocol scheduled from completion routines, but it can be >done. According to TechNote 180, context switching can occur with pending Device Manager calls, but not File Manager calls. Furthermore, your ioCompletion routine will get called when the Device Manager call has completed, even if you are swapped out. This looks like the obvious place to implement a file transfer protocol that must have regular periodic service. No pain, no gain! > >>The protocols used by VersaTerm use handshaking on each packet. You >>don't get a new packet, in other words, until you acknowledge the last >>one. With these protocols, you can actually pause a fairly long time >>between times when you service the file transfer. I suspect that >>VersaTerm doesn't do anything special to make sure it gets time, but >>that you just never see it time out because you never push it that >>hard. > >Um, not with XMODEM. Most implementations will time out if they don't >get an acknowledgement before the timeout period expires. Doesn't >VersaTerm use XMODEM? VersaTerm uses three or four variations of XMODEM and also Kermit. Yes, these will all time out after a certain period. However, it is possible to make a sender pause simply by waiting before you handshake any packet. The exact timeout period will vary, but in my experience XMODEM and Kermit are quite forgiving and will wait a long time before they give up on you. I suspect that there are more problems implementing a streaming protocol like ZMODEM properly, especially when doing downloads. This is simply because you cannot make the sender pause at fairly arbitrary times as you can with one of the packetized protocols. Earle R. Horton
beard@ux1.lbl.gov (Patrick C Beard) (11/27/89)
In article <9072@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >I wonder how they do that. Can anyone provide any information? My >first thought was to schedule your file transfer protocol off the >vertical retrace manager, but your tasks don't get called when you're >switched out. Ah, but one of the Multi-Finder technotes states that vbl tasks that are in the System Heap will continue running even in other contexts. Here's how I do it: struct jump_vector { short jmp; /* place to stuff a 0x4e21 jump instruction. */ ProcPtr addr; /* the place to jump to. */ }; typedef struct jump_vector jump_vector; ... main() { jump_vector *the_jump; the_jump = (jump_vector*)NewPtrSys(sizeof(jump_vector)); ... the_jump->jmp = 0x4e21; the_jump->addr = (ProcPtr)vbl_routine; /* routine we want called. */ /* then, call VInstall with the vblAddr field of your VBLTask record set to point to the_jump... */ ... } ------------------------------------------------------------------------------- - Patrick Beard, Macintosh Programmer (beard@lbl.gov) - - Berkeley Systems, Inc. ".......<dead air>.......Good day!" - Paul Harvey - -------------------------------------------------------------------------------
tim@hoptoad.uucp (Tim Maroney) (11/28/89)
In article <9071@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >If you start an upload and then go into StuffIt to extract information >from the file you just downloaded, StuffIt will refuse to give any time >to the rest of the system until it completes, and your upload will time >out. This is more of a problem, and it *is* an intrinsic problem that >can only be solved with time-sliced multitasking. In article <1487@sequent.cs.qmc.ac.uk> jeremyr@cs.qmc.ac.uk (Jeremy Roussak) writes: >While not disagreeing with the very valid point you're making, Tim, you >malign StuffIt. There's an option in the preferences dialogue (yes, >I'm English) to tell StuffIt to allow time to background tasks. Yes, so a number of people have informed me. However, they also inform me that it's very slow. I doubt anyone keeps their preferences set to allow background time, for this reason -- StuffIt is already tremendously slow. It can easily take 40 minutes to compress and segment two megabytes. So, if you forget to change your preferences to allow this, your transfer will time out, and even highly skilled computer professionals frequently make this class of error. In any case, I was only using StuffIt as an example. There are plenty of programs that don't allow any time to background tasks, and a programmer can always write more. This is a problem that, again, can only be solved by time-sliced multitasking. But it is not usually a problem -- it has an effect only on a few rare cases like file uploading and downloading in terminal emulators. So I am not using this as a way of condemning non-time-sliced multitasking; an argument could be made that it would be more efficient simply to allow some enhanced time-sliced mini-tasking capability for just those few tasks that need it (like a VBL queue that runs regardless of the current context). It should also be noted that the Communications Toolbox File Transfer Manager is hopelessly incompatible with any such scheduling system. It requires synchronous-level idle-time polling. The TOPS background scheduling mechanism would work in most cases, but of course, it's a proprietary trade secret, and I can't tell you what it is, or use it myself in any products. It would be nice if someone with no privileged knowledge would spend the few hours it would take with a debugger to crack it and post a description to the net, so we could all use this nifty thing. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Starting in a hollowed log of wood -- some thousand miles up a river, with an infinitesimal prospect of returning! I ask myself 'Why?' and the only echo is 'damned fool! ... the Devil drives!" -- Sir Richard Francis Burton in correspondence to Monckton Miles, 1863
gft_robert@gsbacd.uchicago.edu (11/28/89)
In article <24453@cup.portal.com>, ts@cup.portal.com (Tim W Smith) writes... >Will Versaterm still work right in the background if you go to another >application, pull down a menu, and just stay there with the meny pulled >down? Good point. I was just making the comment in my original posting that *for all practical purposes* I never have had to worry about VersaTerm timing out. Now it may quite well be that if you push it to the limits it'll mess up. My main point was that -- while far from perfect -- the current Mac implementation of multitasking is pretty good. Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
tim@hoptoad.uucp (Tim Maroney) (11/28/89)
In article <6391@tank.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: >Sounds like it's your comm program, not the Mac OS. I've never had any >problems of that nature when downloading (using Versaterm). I can choose >menus, play games, etc. Pretty good multitasking, as far as I'm concerned. From article <9072@hoptoad.uucp>, by tim@hoptoad.uucp (Tim Maroney): > I wonder how they do that. Can anyone provide any information? My > first thought was to schedule your file transfer protocol off the > vertical retrace manager, but your tasks don't get called when you're > switched out... In article <1554@cbnewsk.ATT.COM> ech@cbnewsk.ATT.COM (ned.horvath) writes: >Unless you install the VBL task in the System heap. See TN 180 for a full >discussion. Thanks! (Although I wonder whether a single brief sentence in a long and boring technical note really qualifies as "a full discussion".) This could be used, as long as you're not using the Communications Toolbox for your file transfers, but rolling your own file transfer protocols instead. In re-reading that note, I also discovered that what I said about device completion routines was wrong. MultiFinder *will* switch if there are async device requests pending; it only refuses to switch if async file requests are pending, not device requests. So a hand-rolled file transfer protocol could indeed schedule itself off asynchronous device manager request completion routines. Or could it? It will also need to do file manager requests, and it doesn't seem safe to do this either synchronously or asynchronously. You can't make a synchronous request from a completion routine or the system could deadlock; you can't call it asynchronously or you risk confusing MultiFinder -- this might just be a problem for the user (not being able to switch layers), not a system-crash-type problem, but I wouldn't like to bet my code reliability on it. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "I don't know that atheists should be considered citizens, nor should they be considered patriots. This is one nation under God." -- George Bush in FREE INQUIRY magazine, Fall 1988
time@oxtrap.oxtrap.UUCP (Tim Endres) (11/28/89)
True multitasking is just that: TRUE. While most users do not "need" true multitasking, you can not dismiss it flippantly. I constantly wish I had true multitasking. Can you spell "Telebit"? I thought you could. 19200bps does funny things to a machine that does not time slice programs well. And how about those menu scans? What? You like to pull down menus and flip through them? A habit you say? And man, the next time I go to click in a menu, and I get NOTHING, because my friendly background printing has tied the CPU, I am going to remember: "There is *no* perceptable difference to the user". Yeah, right.
amanda@intercon.com (Amanda Walker) (11/28/89)
In article <TIME.89Nov27154310@oxtrap.oxtrap.UUCP>, time@oxtrap.oxtrap.UUCP (Tim Endres) writes: > True multitasking is just that: TRUE. Sigh. I guess it's that time of year again. Try the following: go to a good university or scientific bookstore. Pick up a good textbook on operating systems, and read through the sections on multitasking. Multitasking is an overall term that covers a variety of different techniques, much in the same way that "virtual memory" does. The term "multitasking" simply means that a single processor is shared among several different programs in order to gove the illusion that a computer is doing more than one thing at once. "True multitasking" doesn't mean anything, although many people use it to mean "The kind of multitasking that I am used to on other machines," whatever that may be. This makes its definition a political issue, not a technical one. In case you are unfamiliar with them, here are some simple definitions of the major different types of multitasking: Cooperative Multitasking: In this technique, control of the processor is given up explicitly by each task. This is used by many real-time operating systems, internally within conventional UNIX kernels, most MS-DOS multitasking extensions, and MultiFinder. Pre-emptive Multitasking: In this technique, control of the processor is switched from task to task my means of a hardware interrupt, thus preventing any single process from monopolizing the processor, at the expense of guaranteed response time. This technique is used by most UNIX user process schedulers, the Commodore Amiga Operating System, and most "time-sharing" operating systems. Either of these techniques can be used in conjunction with other processing techniques, such as multiple independent address spaces (also called "protected memory"), threads (multiple simultaneous logical processes within a single address space), time-slicing, virtual memory, process swapping, or paging. However, none of these has anything to do with whether or not the machine "has true multitasking" or not. For a Macintosh, MultiFinder does an excellent job of allocating time and resources. For an example, Try running a Mac binary on a heavily loaded (or even lightly loaded :-)) A/UX system--it's pre-emptive, and it makes everything equally slow. Under MultiFinder, things stay generally pretty quick, in comparison. For most things, I'd actually rather use my Mac II with MultiFinder than a Sun 3 with the same amount of memory running UNIX, since I get to control how slow it gets... Complaining that "the Macintosh doesn't have the kind of multitasking I think I want" is fine. Complaining that it doesn't have "true multitasking" just demonstrates ignorance. Amanda Walker InterCon Systems Corporation --
ghe@nucthy.physics.orst.edu (Guangliang He) (11/28/89)
In article <1574@intercon.com> amanda@intercon.com (Amanda Walker) writes: [some text deleted] > For a Macintosh, MultiFinder does an excellent job of allocating time and > resources. For an example, Try running a Mac binary on a heavily loaded > (or even lightly loaded :-)) A/UX system--it's pre-emptive, and it makes > everything equally slow. Under MultiFinder, things stay generally pretty > quick, in comparison. For most things, I'd actually rather use my Mac II > with MultiFinder than a Sun 3 with the same amount of memory running UNIX, > since I get to control how slow it gets... > > Complaining that "the Macintosh doesn't have the kind of multitasking > I think I want" is fine. Complaining that it doesn't have "true multitasking" > just demonstrates ignorance. > > Amanda Walker > InterCon Systems Corporation > -- Complaining that you can't control the speed of a job on a UNIX machine is ignorance, too. On a UNIX machine, you really get the control you want. Although you can't go too faster (get a cray if you really want fast). you can always slow your job. Nice the job, put it in background. Do whatever you want. But I fail to see how good contral I can have under Multifinder. Maybe someone could tell me how to control the speed of a job under multifinder. ======================================================================= USMAIL: Guangliang He | INTERNET: ghe@PHYSICS.ORST.EDU Department of Physics | BITNET: hegl@ORSTVM.BITNET Weniger Hall 301 | Oregon State University | Corvallis, OR 97331-6507 | PHONE: (503) 737-4631 =======================================================================
dave@etsu.CMI.COM (David Halonen) (11/28/89)
In article <14002@orstcs.CS.ORST.EDU> ghe@nucthy.PHYSICS.ORST.EDU (Guangliang He) writes: >[some deleted text] Nice the job Come on now. Who actually does this? Besides, in examining the algorithm for 'nice', one can see that it only makes a piddly small difference anyway. BTW, what was the original thinking when this was implemented? Since when do time sharing users wish to be nice to each other? Perhaps this goes back to Unix's original roots of a couple of programmers sitting together in a room sharing a cpu, and saying to each other, "Come on, be nice to me." Or did Tina say that? I'm sorry, I digress. David Halonen, Center for Machine Intelligence, Electronic Data Systems Ann Arbor, MI (313) 995-0900 AppleLink: N0548 Internet: dave@cmi.com
d88-jwa@nada.kth.se (Jon Watte) (11/28/89)
In article <14002@orstcs.CS.ORST.EDU> ghe@nucthy.PHYSICS.ORST.EDU (Guangliang He) writes: >Complaining that you can't control the speed of a job on a UNIX machine >is ignorance, too. On a UNIX machine, you really get the control you >want. Although you can't go too faster (get a cray if you really want >fast). you can always slow your job. Nice the job, put it in So why do the sysops here swear over BSD job-scheduling ? Yes, because you can't nice much enough. You can't say "Run this process only while the load drops below 3.8". I hear IBM is good on these things (they SURE know how to take care of batches :-) The sun always shines in my mac h+ -- ALL of it, NOW ! -- If you wanna see my *real* .sig, mail h+@nada.kth.se or h+@proxxi.se
amanda@intercon.com (Amanda Walker) (11/28/89)
In article <14002@orstcs.CS.ORST.EDU>, ghe@nucthy.physics.orst.edu (Guangliang He) writes: > On a UNIX machine, you really get the control you > want. Although you can't go too faster (get a cray if you really want > fast). you can always slow your job. And so can anyone else, whether you want them to or not. MultiFinder doesn't let you control process priority from outside the program, I admit, and it would occasionally be nice to be able to override an application's minimum timeslice interval (which is why our applications let users do it :-)). Look, every multitasking system has its own strengths and weaknesses. "Fair" scheduling (or even UNIX-style scheduling) is much more appropriate for a multi-user system (like a VAX) than for a single-user system (like a Mac). Under MultiFinder, the application I am interacting with gets the most CPU share, and even more importantly, gets to control when it gives it up. This means that even if I'm compiling 70,000 lines of C in the background (which I actually do from time to time), I can still sit and read my mail or news without noticing much of a difference in response time. Do that on a Sun with 4M of memory and a window system :-). Amanda Walker InterCon Systems Corporation --
ghe@nucthy.physics.orst.edu (Guangliang He) (11/29/89)
In article <2421@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes: > In article <14002@orstcs.CS.ORST.EDU> ghe@nucthy.PHYSICS.ORST.EDU (Guangliang He) writes: > > >Complaining that you can't control the speed of a job on a UNIX machine > >is ignorance, too. On a UNIX machine, you really get the control you > >want. Although you can't go too faster (get a cray if you really want > >fast). you can always slow your job. Nice the job, put it in > > So why do the sysops here swear over BSD job-scheduling ? > Yes, because you can't nice much enough. You can't say > "Run this process only while the load drops below 3.8". > So, please tell me how to do this type thing under multifinder. ======================================================================= USMAIL: Guangliang He | INTERNET: ghe@PHYSICS.ORST.EDU Department of Physics | BITNET: hegl@ORSTVM.BITNET Weniger Hall 301 | Oregon State University | Corvallis, OR 97331-6507 | PHONE: (503) 737-4631 =======================================================================
billkatt@mondo.engin.umich.edu (billkatt) (11/29/89)
In article <14002@orstcs.CS.ORST.EDU> ghe@nucthy.PHYSICS.ORST.EDU (Guangliang He) writes: >In article <1574@intercon.com> amanda@intercon.com (Amanda Walker) writes: >[some text deleted] >> For a Macintosh, MultiFinder does an excellent job of allocating time and >> resources. For an example, Try running a Mac binary on a heavily loaded >> (or even lightly loaded :-)) A/UX system--it's pre-emptive, and it makes >> everything equally slow. Under MultiFinder, things stay generally pretty >> quick, in comparison. For most things, I'd actually rather use my Mac II >> with MultiFinder than a Sun 3 with the same amount of memory running UNIX, >> since I get to control how slow it gets... >> [some text deleted] >Complaining that you can't control the speed of a job on a UNIX machine >is ignorance, too. On a UNIX machine, you really get the control you >want. Although you can't go too faster (get a cray if you really want >fast). you can always slow your job. Nice the job, put it in the >background. After a little experience with UNIX you should know that this is not true, either. You can nice a job, but if it uses a large amount of virtual memory it will still slow your machine to a standstill even at the most nice level. This is because swapping takes processor time and the swapper runs under its own time. I'm sure you've noticed this effect if you've ever tried to nice an X server or some other similar huge program. -Steve
peirce@claris.com (Michael Peirce) (11/29/89)
In article <1250@smurf.ira.uka.de> urlichs@smurf.ira.uka.de (Matthias Urlichs) writes: >In comp.sys.mac.programmer tim@hoptoad.UUCP (Tim Maroney) writes: >< In article <17247@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu >< (Earle R. Horton) writes: >< >< I thought that MultiFinder would refuse to context switch if the file >< or device system had any pending asynchronous requests. But maybe I'm >< thinking of an earlier incarnation. It's fairly painful to write a >< complete protocol scheduled from completion routines, but it can be >< done. >< >MF currently checks if the file manager is busy. The device manager is not >checked. So the file I/O requests occur on top of whatever application may be >running at the moment. No problem (but check if you have enough room on the >stack!) >I would not describe running a protocol from completion routines as painful. >It's more like a lot of typing. (I ought to know :-) -- my soon-to-be-released >AppleShare-compatible server works that way.) >-- >Matthias Urlichs I agree with Matthias, setting up a protocol that only depends on completion routines isn't really all that painful. You just have to understand how to program using state machines. Public Folder uses this model - everything done on the server side is 100% completion routines. It just sits there waiting for an incoming request, then hangs a read (say), then waits for it to complete, then sends it back, etc... [think about it, there's no App around for PF to be a part of!] Of course, PF is using ATP and the file system, but serial i/o should work the same. [actually you have to roll your own timeouts with the timeMgr, but again, not to hard to do.] Claris Corp. | Michael R. Peirce -------------+-------------------------------------- | 5201 Patrick Henry Drive MS-C4 | Box 58168 | Santa Clara, CA 95051-8168 | (408) 987-7319 | AppleLink: peirce1 | Internet: peirce@claris.com | uucp: {ames,decwrl,apple,sun}!claris!peirce
amanda@intercon.com (Amanda Walker) (11/29/89)
In article <10702@claris.com>, peirce@claris.com (Michael Peirce) writes: > I agree with Matthias, setting up a protocol that only depends on completion > routines isn't really all that painful. You just have to understand how to > program using state machines. In fact, thinking of your code as a state machine is an extremely effective technique for Macintosh programming in general, especially when I/O of any sort is involved. It makes a lot of potential difficulties evaporate (by, of course, introducing others :-)). In particular, it makes it much easier to make the code friendly to other things going on at the same time, since you don't spend any time waiting for stuff that hasn't happened yet. -- Amanda Walker InterCon Systems Corporation amanda@intercon.com
francis@mirror.UUCP (Joe Francis) (11/30/89)
In article <1574@intercon.com> amanda@intercon.com (Amanda Walker) writes: >In article <TIME.89Nov27154310@oxtrap.oxtrap.UUCP>, time@oxtrap.oxtrap.UUCP >(Tim Endres) writes: >> True multitasking is just that: TRUE. > >Sigh. I guess it's that time of year again. ... >Cooperative Multitasking: > > In this technique, control of the processor is given up explicitly by ... >Pre-emptive Multitasking: > > In this technique, control of the processor is switched from task to ... and don't forget "HyperTrue" multitasking: such as having a quickdraw coprocessor or multiple cpu's, or having a bunch of Macs all tied together on a network. If Tim was disappointed with the differences between cooperative and preemptive, he'll shun preemptive after he's seen "HyperTrue"!
ted@hpwrce.HP.COM ( Ted Johnson) (11/30/89)
>>[some deleted text] Nice the job > >Come on now. Who actually does this? Besides, in examining the I usually use nice(1) to be NOT nice, when I want something to get done in a hurry (e.g., nice --19 cpu_pig). Unfortunately, the effect of the negative nice doesn't last long, since the scheduler detects that cpu_pig is cpu-bound, and quickly degrades its priority. -Ted
amanda@intercon.com (Amanda Walker) (12/01/89)
In article <33410@mirror.UUCP>, francis@mirror.UUCP (Joe Francis) writes: > and don't forget "HyperTrue" multitasking: such as having a quickdraw > coprocessor or multiple cpu's Well, luckily most people still call that "multiprocessing", although as it becomes more prevalent, people will probably start arguing about it, too. I can hear it now... "Well, I know I have 6 I/O processors and a graphics engine, but when will I get *real* multiprocessing?" "What you probably mean is *symmetric* multiprocessing." "Everybody knows that's the only real kind..." Sigh. Grin. It's always something. -- Amanda Walker InterCon Systems Corporation amanda@intercon.com
pem@cadnetix.COM (Paul Meyer) (12/02/89)
In article <1487@sequent.cs.qmc.ac.uk> jeremyr@cs.qmc.ac.uk (Jeremy Roussak) writes: >While not disagreeing with the very valid point you're making, Tim, you >malign StuffIt. There's an option in the preferences dialogue (yes, >I'm English) to tell StuffIt to allow time to background tasks. Unfortunately, from my experiments, checking that box makes stuffit spend a lot of time redrawing its status window, but gives very little time to background tasks. I watch my modem status lights to check this, and in fact no pending data goes out regardless of which way you set the box. (sigh) I suspect this will be fixed in the commercial Stuffit when it comes out, but I have neither omniscience nor a line to Ray Lau. Paul Meyer pem@cadnetix.COM Daisy/Cadnetix Inc. (DAZIX) {uunet,boulder}!cadnetix!pem 5775 Flatirons Pkwy. GEnie P.MEYER CI$ 73627,1274 Boulder, CO 80301 (303)444-8075x277
time@oxtrap.oxtrap.UUCP (Tim Endres) (12/02/89)
In article <1083@etsu.CMI.COM> dave@etsu.CMI.COM (David Halonen) writes:
Come on now. Who actually does this? Besides, in examining the
algorithm for 'nice', one can see that it only makes a piddly small
difference anyway.
We do. In real time systems implemented on Unix (a bit of a
contradiction I understand) this little priority change can completely
change the dynamics of our environment.