lim@iris.ucdavis.edu (Lloyd Lim) (07/21/90)
I am writing an app that I want to be as MultiFinder friendly as possible.
Therefore, when I call WaitNextEvent with a sleep value of 0xFFFFFFFF (the
app doesn't run on Systems with the sleep bug). Unfortunately, I noticed
that when I do this, Pyro and some other things stop working. If I move the
mouse to the sleep now corner, Pyro won't activate. Scope, the magnifying
glass DA, also does not work correctly.
If I call WNE with a smaller sleep value like 10, Pyro and Scope work ok.
Am I correct in diagnosing these problems as bugs in Pyro and Scope? Is there
anything I can do to avoid problems like these? Apparently, nobody expected
that MultiFinder would ever sleep for a long time.
+++
Lloyd Lim Internet: lim@iris.ucdavis.edu (128.120.57.20)
Compuserve: 72647,660
US Mail: 146 Lysle Leach Hall, U.C. Davis, Davis, CA 95616hairston@henry.ece.cmu.edu (David Hairston) (07/22/90)
[lim@iris.ucdavis.edu (Lloyd Lim) writes:] [] I am writing an app that I want to be as MultiFinder friendly as possible. [] Therefore, when I call WaitNextEvent with a sleep value of 0xFFFFFFFF (the [] app doesn't run on Systems with the sleep bug). Unfortunately, I noticed umm, i seem to recall a tech note (sorry i don't remember the number but you could check the sumex archives, info-mac/apple/tn) that stated that the largest sleep never exceed 50L for empirically derived reasons. perhaps that is the source of your problem? -dave- hairston@henry.ece.cmu.edu
mosemann@hoss.unl.edu (Russell Mosemann) (07/22/90)
In <HAIRSTON.90Jul21162608@henry.ece.cmu.edu> hairston@henry.ece.cmu.edu (David Hairston) writes: >[lim@iris.ucdavis.edu (Lloyd Lim) writes:] >[] I am writing an app that I want to be as MultiFinder friendly as possible. >[] Therefore, when I call WaitNextEvent with a sleep value of 0xFFFFFFFF (the >[] app doesn't run on Systems with the sleep bug). Unfortunately, I noticed >umm, i seem to recall a tech note (sorry i don't remember the number but >you could check the sumex archives, info-mac/apple/tn) that stated that >the largest sleep never exceed 50L for empirically derived reasons. >perhaps that is the source of your problem? > -dave- >hairston@henry.ece.cmu.edu A bug in the early MultiFinder did not allow a time larger than 50L. That has since changed. If you are using the latest MultiFinder, you should be able to put any time in. I believe Lloyd is saying the same thing when he states "...the app doesn't run on Systems with the SLEEP BUG [emphasis mine]..." Russell mosemann@hoss.unl.edu
keith@Apple.COM (Keith Rollin) (07/23/90)
In article <HAIRSTON.90Jul21162608@henry.ece.cmu.edu> hairston@henry.ece.cmu.edu (David Hairston) writes: >[lim@iris.ucdavis.edu (Lloyd Lim) writes:] >[] I am writing an app that I want to be as MultiFinder friendly as possible. >[] Therefore, when I call WaitNextEvent with a sleep value of 0xFFFFFFFF (the >[] app doesn't run on Systems with the sleep bug). Unfortunately, I noticed > >umm, i seem to recall a tech note (sorry i don't remember the number but >you could check the sumex archives, info-mac/apple/tn) that stated that >the largest sleep never exceed 50L for empirically derived reasons. >perhaps that is the source of your problem? I think that this was a MultiFinder 1.0 bug that's since been fixed (and that this is what Lloyd is referring to as the "sleep bug"). I think that what Lloyd is running into is the problem where MultiFinder doesn't think that anyone needs time to run, so it just spins its gears until it's time to handle an event or wake up an application. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
llama@eleazar.dartmouth.edu (Joe Francis) (07/25/90)
>lim@iris.ucdavis.edu (Lloyd Lim) writes: >I am writing an app that I want to be as MultiFinder friendly as possible. >Therefore, when I call WaitNextEvent with a sleep value of 0xFFFFFFFF (the >app doesn't run on Systems with the sleep bug). Unfortunately, I noticed Despite the fact that WaitNextEvent has the sleep parameter defined as an unsigned long, I notice that the Apple sample code "Sample.c" and "TESample.c" use MAXLONG for their "don't need no time" sleep value. Paranoid double checking of Values.h revealed that MAXLONG is indead 0x7FFFFFFF. Now I wonder why they did that? hmmmm... ------------------------------------------------------------------------------ "Read My Lips: No Nude Texans!" - George Bush clearing up a misunderstanding and tackling one of the great problems of our time Of course, Souter has expressed doubts about the constitutionality of federally regulating nude Texans....
beard@ux5.lbl.gov (Patrick C Beard) (07/26/90)
In article <43256@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: #In article <HAIRSTON.90Jul21162608@henry.ece.cmu.edu> hairston@henry.ece.cmu.edu (David Hairston) writes: #>[lim@iris.ucdavis.edu (Lloyd Lim) writes:] #>[] I am writing an app that I want to be as MultiFinder friendly as possible. #>[] Therefore, when I call WaitNextEvent with a sleep value of 0xFFFFFFFF (the #>[] app doesn't run on Systems with the sleep bug). Unfortunately, I noticed #> #I think that what Lloyd is running into is the problem where MultiFinder #doesn't think that anyone needs time to run, so it just spins its gears #until it's time to handle an event or wake up an application. This is exactly what is going on. I have seen this before. The problem seems to be that Multifinder doesn't call SystemTask() from within this idle time. It should. I hope system 7 has a better scheduler. -- ------------------------------------------------------------------------------- - Patrick Beard, Macintosh Programmer (beard@lbl.gov) - - Berkeley Systems, Inc. ".......<dead air>.......Good day!" - Paul Harvey - -------------------------------------------------------------------------------