I want to know if an application running in a different desktop (or screen) is frozen. Is a frozen application running?
It would depend very much on how it is frozen.
It probably still counts as running as far as Keyboard Maestro is concerned, whether it is frozen or not.
Possible you could ask it a question via AppleScript, with a short timeout and see if that works or fails to determine if it is entirely frozen. But it could be quite frozen and still respond.
Peter already gave a good answer, but I want to throw in my two cents anyway. Would a program in an infinite loop constitute a frozen program? It's still running, just in an infinite loop. Would that program be "frozen?" What about non-infinite loops that are very long and slow? I've seen programs that don't display anything for the first 10 or 20+ seconds after they launch. They feel frozen but I guess they are just loading files and whatnot. When the Activity Monitor in macOS says "not responding" it probably means the program isn't responding to a signal from macOS. But that doesn't mean the program is permanently frozen. Ultimately it's you who determines if a program is frozen.
Your question is actually related to one of the most intriguing problems in computer science:
To get information on the process state you could use the ps tool. From the man page:
state The state is given by a sequence of characters, for example,
``RWNA''. The first character indicates the run state of the
process:
I Marks a process that is idle (sleeping for longer than
about 20 seconds).
R Marks a runnable process.
S Marks a process that is sleeping for less than about 20
seconds.
T Marks a stopped process.
U Marks a process in uninterruptible wait.
Z Marks a dead process (a ``zombie'').
And further:
Additional characters after these, if any, indicate additional
state information:
+ The process is in the foreground process group of its
control terminal.
< The process has raised CPU scheduling priority.
> The process has specified a soft limit on memory
requirements and is currently exceeding that limit;
such a process is (necessarily) not swapped.
A the process has asked for random page replacement
(VA_ANOM, from vadvise(2), for example, lisp(1) in a
garbage collect).
E The process is trying to exit.
L The process has pages locked in core (for example, for
raw I/O).
N The process has reduced CPU scheduling priority (see
setpriority(2)).
S The process has asked for FIFO page replacement
(VA_SEQL, from vadvise(2), for example, a large image
processing program using virtual memory to sequentially
address voluminous data).
s The process is a session leader.
V The process is suspended during a vfork(2).
W The process is swapped out.
X The process is being traced or debugged.
Example (ps <pid>):
“S” seems to be the most “normal” state (very likely not frozen). When you get any of the other letters, it’s up to you to decide if the process is “frozen”.
In a short test I get “R” for example when the process is busy doing something (beachball, for example BBEdit opening a huge file).
Thanks for sharing, @Tom. 
I'll have to try this on the next beachball I get.
Where do you get the <pid> from?
For example from the Activity Monitor (/Applications/Utilities/Activity Monitor.app):
…or you go for the process by name in the shell with for example: ps ax | grep -i bbedit
1 Like
Tom, do you know which of the state(s) above the macOS GUI (eg, the Activity Monitor) uses to determine when to indicate to us that the program is "not responding"?
No, I don’t know. And I don’t think that Activity Monitor is just a GUI for the ps tool (please correct me if I’m wrong).
Just throw a 400MB PDF at BBEdit and you’ll have plenty of time to explore it 
1 Like
Just some technical details - and mostly I am just guessing. But in terms of “sleeping” and “runable”, these are probably relating to very low level threading concepts, such as whether the process is waiting for IO to respond. For example, if a process reads from the disk, then it will be sleeping waiting for the OS to read the data, and “runable” when the data has been fetched.
It is likely that while an app is waiting for events to process and not doing much, it will mostly be sleeping. But it will also likely wake up periodically to do things (certainly if it has any background processing, including stuff like displaying state or periodic saving or whatever).
In terms of the OS concept of “not responding”, that would likely be related to the app not processing events on the event queue. This is quite a difference concept.
So an app that is “not responding” could be frozen in a loop (“runable”) or frozen waiting for IO (especially network) (“sleeping”), or it could be doing other stuff and just not processing the event queue (eg rendering a large PDF for printing) (which could be “runable” or “sleeping” depending on what exactly it is doing).
I would guess the best way to determine if a application is “not responding” would be to send it a trivial AppleEvent/AppleScript request and see if it responds in a timely manner. Presuming there is some AppleEvent it can respond to (or perhaps even an AppleEvent that it does not handle would work, since you would get a response back saying it is not handled, but only after the app had a chance to say so).
1 Like
Thanks for your insight. I'll bet that programs are "sleeping" a lot more than we think. For example, when a program is "waiting" for a file to be saved, it's probably "sleeping" for about 99% of that time. A well written program may have several "threads" and each thread could have its own status vis-a-vis "sleeping" or "running". I'm not sure if these threads show up as separate processes from the "ps" command.
Hey JM,
This is a chicken vs egg question.
A PID cannot be used productively unless you already know it.
Usually you'll want to find it via a command name like so:
I'm returning both BBEdit and the headers here:
ps auxc | egrep -i "^user|bbedit"
Another means of finding the PID via AppleScript:
tell application "System Events"
set pidNum to unix id of process "BBEdit"
end tell
Sometimes an error mechanism will give you a PID number and nothing else, and that's when ps <PID> genuinely comes in handy.
For the task at hand it's likely that top in logging mode will provide more useful information.
top -l 3
This will make 3 passes. The first pass is a complete throwaway, because it's unlikely to be correct.
Pass number 2 is probably okay, and I believe I've used it satisfactorily in the past – but I haven't played with top for some time.
-Chris
1 Like
Thanks Chris. Evernoted for future ref.