Re: detecting when an app is beach-balling
Re: detecting when an app is beach-balling
- Subject: Re: detecting when an app is beach-balling
- From: Half Activist <email@hidden>
- Date: Tue, 23 Oct 2007 08:35:34 +0200
There is one very important point you should think about: How to
recognise a finite loop from an infinite loop?
It seems this problem IS the "Halting Problem", therefore it's an
undecidable problem. Sure this can be a human decidable problem, but
machine can't and won't.
Really, how would a machine do? based on assumptions? A loop that
lasts more than n is considered infinite? or on processor state changes?
Furthermore, an infinite loop can be sane. Isn't the processor
scheduler looping infinitely over processes to schedule? I mean,
while not told to stop an operating system is supposed to run forever.
So an application that's not responding to events has only stopped to
do so, and you can't tell anything else. So it's finally up to the
user to decide to wait till is finally responds again, or kill it.
It's just as if in the terminal, you'd launch a program that takes
some time and then the system would print out 'I've waited the
termination for too long, I'm bailing out'.
Regards.
On Oct 23, 2007, at 4:17 AM, William Squires wrote:
Hmmm, this all has me wondering if Apple & Intel engineers are
(or should be) listening in on this thread. In embedded-systems
design, many (if not all) micro-controllers have a WDT (Watch Dog
Timer) that will reset the micro-controller if it hangs (gets in an
infinite loop). While such would be useless by itself, it would be
handy if a (new) processor (Intel Core 3 Duo, anyone? or an 8-core
Xeon) could "attach" a WDT to a thread with a programmable delay
(ideally stored in a 64-bit special-purpose register, indexed by
thread). "ordinary" threads could be given a "reasonable" delay by
OS X, while computation-intensive threads could be given the
longest delay possible so that the thread wouldn't be stopped
prematurely by the WDT. Of course, this would require an API so
those doing scientific research on OS X with Xcode/Cocoa could give
their computation threads a greater delay. Maybe via NSWorkspace?
Still, using only software, I'm not sure you can do this as any
app/process/thread that hangs will also hang any process that tries
to determine its state, unless is has a timeout (like the WDT
above) or a pattern-recognition algorithm which would say "hey, the
current state of thread N is significantly different/same than the
last X samples of the thread execution."
IIRC, this is related to the "stopping" theory put forth by early
pioneers in computing that stated (roughly) that you couldn't prove
- using a system of logic or mathematics - that a computer program
would ever terminate (unless it was trivially simple.)
Just my $0.02.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden