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: William Squires <email@hidden>
- Date: Mon, 22 Oct 2007 21:17:44 -0500
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.
On Oct 22, 2007, at 12:01 PM, has wrote:
Martin Redington wrote:
yep, that wil send a misc/actv event to the app, and activate it
miscactv (activate) = bring to front, so you don't really want to
use that.
(starting it if its not started already, or bringing it to the front
otherwise).
Note that application launching is unrelated to Apple events. The
Apple Event Manager is not able to launch applications itself.
AppleScript automatically launches a non-running application by
calling the Carbon Process Manager's LaunchApplication() (there's
also LaunchServices' LSLaunchApplication() in 10.4+).
ascr/gdte seems to do what I want for running apps, but not for non-
scriptable apps (I'm presuming that I'll only be polling running
apps).
'ascrgdte' = 'get dynamic AppleScript terminology'. It will work
for any application as the OS provides a default ascrgdte event
handler that calls through to OSAGetAppTerminology. If an
application doesn't have a terminology resource, the reply event
will contain a 'resource not found' error (-192).
Ron Fleckner wrote:
-- begin AppleScript
[...]
-- end AppleScript
will start up any app, whether it's scriptable or not. Of course,
you have to name your target app properly, that is, substitute a
real name for "AnyApplication".
Those would be two pretty good reasons to avoid using the
AppleScript language. You probably don't want the application being
launched automatically if it isn't already running, and you
definitely don't want one of those wretched 'Where is
application...?' dialogs appearing if AppleScript can't immediately
locate the application in question. A third reason would be if you
wanted to perform this test from a non-main thread, for which
AppleScript is teh suck.
Anyway, the standard 'no-op' event is ascrnoop. The AppleScript
equivalent is 'tell app "Foo" to launch', with the caveat that
AppleScript treats this command as a special case and always sends
it with a kAENoReply flag. That's no good if you're wanting to wait
for a reply event, but it's a non-issue if you send the event via
another method.
Assuming you don't tell the Apple Event Manager to wait forever for
a reply event (you can specify the timeout delay when you send the
event), what you're looking for is an 'event timed out' error
(-1712) returned by AESend()/AESendMessage() to tell you if the
application (specifically its main thread) is busy, or 'no
error' (0) to tell you that the event was received and responded to
(you'll also get a reply event containing an 'event not recognised'
error, -1708, which you can just ignore).
To build and send your event, you could use objc-appscript's AEM
API (which provides a convenient ObjC wrapper around the Apple
Event Manager API) to send the relevant event, or it's a simple
enough task that you could do pack and send the event yourself
using NSAppleEventDescriptor and AESendMessage. If you need example
code, just ask.
HTH (and touch-wood I got that all correct...)
has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
_______________________________________________
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:
40satx.rr.com
This email sent to email@hidden
_______________________________________________
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