🚀 go-pugleaf

In article <nevin-0602962253080001@150.135.1.79>,
Nevin ":-]" Liber <nevin@CS.Arizona.EDU> wrote:
>In article <kevinbDMCMIy.B26@netcom.com>, kevin@frobozz.sccsi.com (Kevin
>Brown) wrote:
>
>> Fine.  Then try running a "brain-dead" program like this instead:
>
>>         main()
>>         {
>>             while ( there_is_useful_work_to_be_done )
>>             {
>>                 do_the_computationally_intensive_useful_work();
>>             }
>>             display_the_results();
>>         }
>
>> where there_is_useful_work_to_be_done remains true for long periods of
>> time (minutes, hours, perhaps even days).
>
>So, you can't figure out how to get this to work well on a Mac, eh? 

Oh, I know how to get it to work...whether it works *well* or not
is another question...

And, in any case, we weren't talking about *modifying* the program,
but *running* it, weren't we?  Don't change the subject.

>Hmmmm...  <in deep thought for 4.2 seconds>  How about putting a
>WaitNextEvent() call in one of the inner loops of
>do_the_computationally_intensive_useful_work();?

Oh, okay, I'll let you change the subject.  :-)

Does WaitNextEvent() block until an event occurs, as its name implies?
If so, then congratulations, you've managed to destroy the usefulness
of the above program.

However, I doubt you're any more of a moron than I am, so I therefore
assume that WaitNextEvent() doesn't block, in which case it's not a
problem to use it in that way.  But it *is* a kludge.

So instead you have an efficiency issue, which is a much more
difficult issue to argue because it depends on so many things.

Now then...you *did* say "work well", didn't you?  Demonstrate that
your solution will work "well" under a variety of conditions like,
say, on many different speeds of CPU.

>Is this really rocket science for you, Kevin?

No, of course it isn't...once I know how the Mac system calls work
(ignorance is a horrible thing).

I'm not a *complete* moron, though there may be some who think I am.
:-)

>I can't wait to see your next completely contrived example that you can't
>figure out how to solve that the rest of us can trivally solve.


Okay...fix the above code so that it will run optimally on all CPUs
(i.e., not make too many or too few calls to WaitNextEvent() in any
given period of time).  Aha...now you have to add a timing loop (to
measure what "optimal" is) and some conditional code.  If it wasn't a
kludge before, it definitely is now.

Now fix it so that it will run optimally on all Mac CPUs from the
slowest to the fastest *and* account for the demand for the CPU from
other applications.

And if that's too simple for you...fix the above code so that it works
well on all Macs under most conditions, where the function

     do_the_computationally_intensive_useful_work()

is a *library* call that (a) can take an arbitrary amount of time to
execute, (b) does not itself invoke WaitNextEven(), and (c) you do not
control but must, nonetheless, use (want to put it in the context of
real life?  Okay...it could easily be an encryption library function).

Or how about this: design the above program so that it *will* get CPU
time when it needs it, while not making the system unusable.


Looking forward to your answers...:-)



P.S.: here's a possible answer to many of these problems: is it
possible for the program to install a timer interrupt handler that can
run in the context of the process that installed it?  If so, you could
program the timer so that after a certain elapsed period of time, the
handler will be invoked, which will call WaitNextEvent() in the
context of the program, such that when control is returned it can
program the timer interrupt and resume execution of the program where
it left off?

I am, of course, thinking along the lines of something akin to the
Unix alarm() function.


-- 
Kevin Brown                                     kevin@frobozz.sccsi.com
This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end >
            This is your .signature virus on drugs: <>
                        Any questions?