UWP (or "Metro") apps in Windows 8/10 are frequently suspended when they are not in the foreground. Apps in this state continue to exist but no longer consume CPU time. This change seems to have been introduced to improve performance on low-power/storage devices like tablets and phones.
Please can I ask, what is the most elegant and simple method to detect an app in this state?
I can see 2 possible solutions at the moment:
Call NtQuerySystemInformation() and the enumerate each process and each thread. A process is "suspended" if all threads are in the suspended state. This approach will require a lot of code and critically NtQuerySystemInformation() is only semi-documented and could be removed in a future OS. NtQueryInformationProcess() may also offer a solution with the same problem.
Call GetProcessTimes() and record the counters for each process. Wait some time (minutes) and check these again. If the process counters haven't changed then assume the process is suspended. This is a hack and I may get shot down for even thinking of it.
Jim
The second one (GetProcessTimes() … wait … and check these again.
If the process counters haven’t changed then assume the process is suspended)
is less reliable.
If a process is waiting for input (e.g., keyboard, mouse, or network)
and not getting any, it will use very little CPU time
and will appear to be suspended by this approach.
I have a working application that needs to clear and setup very large buffers from time to time. Sometimes the operation takes longer than 5 seconds to complete and then Desktop Window Manager times out and declares the application to be hung.
Is there any technique to cause DWM to allow more time before this happens?
Delphi Seattle, Windows 10, 64-bit application
The right solution is to put the long running task in a thread so that it does not block your UI thread. You should do that.
If you cannot bring yourself to take that task one, and it can be quite tricky, you can always disable ghosting by calling DisableProcessWindowsGhosting. But you really ought not to do that. You really ought to put the work in a thread.
is it possible to fire up an event at a specified time interval in BlackBerry? I'm looking for something similar to AlarmManager class in Android (if anyone is familiar with it).
The goal is to is to run some code, even when the application is not in foreground and without it gaining foreground "focus". Preferably it should be possible to fire the event even if the app was killed by system or by phone reboot (I do not know the details about killing apps at this OS, I'm beginning development now).
I would prefer not to write a background process for this task as it is going to be fired every few hours (I think it would be a waste of battery to use a background task for a simple alarm-like event).
I've looked around a lot, but I cannot find any satisfying solution.
cheers,
kajman
The Timer and TimerTask classes are useful for running a task on a schedule. Take a look at the APIs here:
http://www.blackberry.com/developers/docs/7.0.0api/java/util/Timer.html
The Timer will create its own Thread and sleep until it has a task to run. It would involve having a background task running but it wouldn't be using an CPU or battery if it is just waiting.
If you don't want a Thread running all of the time you can use the ApplicationManager class to schedule your application to start later.
You can also configure your app to run on start up. The OS generally won't kill your apps unless you have a coding error. RIM refers to this as the Always-On Experience in their Super App document:
http://docs.blackberry.com/en/developers/deliverables/23567/Always_on_1380986_11.jsp#Keeping_the_app_running_1381022_11
I was planning on writing a small daemon that detected whether another app crashed, thinking all the while that the system would send an NSWorkspaceDidTerminateApplicationNotification, but this is not the case.
Assuming that I do not want to create a launchd process to simply re-launch the crashed application, can I detect the crash any other way?
Perhaps I could monitor the system log? That seems unduly burdensome.
How about watching for if/when the /usr/sbin/spindump process starts up?
Turns out what worked best as a crash monitor was reading the FSEventStream for Crash Logs.
When Mac OS X goes to sleep, due to closing a laptop or selecting "Sleep" from the Apple menu, how does it suspend an executing process?
I suppose non-windowed processes are simply suspended at an arbitrary point of execution. Is that also true for Cocoa apps, or does the OS wait until control returns to the run loop dispatcher, and goes to sleep in a "known" location? Does any modern OS do that, or is it usually safe enough to simply suspend an app no matter what it is doing?
I'm curious, because allowing sleep to occur at any moment means, from the app's perspective, the system clock could suddenly leap forward by a significant amount. That's a possibility I don't usually consider while coding.
Your app is interrupted exactly where it is that moment if the CPU is actually currently executing code of your app. Your app constantly gets execution time by the task scheduler, that decides which app gets CPU time, on which core, and for how long. Once the system really goes to sleep, the scheduler simply gives no time to your app any longer, thus it will stop execution wherever it is at that moment, which can happen pretty much everywhere. However, the kernel must be in a clean state. That means if you just made a call into the kernel (many libC functions do) and this call is not at some safe-point (e.g. sleeping, waiting for a condition to become true, etc.) or possibly holding critical kernel locks (e.g. funnels), the kernel may suspend sleep till this call returns back to user space or execution reaches such a safe-point before it finally cancels your app from the task scheduler.
You can open a kernel port and register for sleep/wake-up events. In that case, your app will receive an event, when the system wants to go to sleep. You have several possibilities. One is to reply to it, that the system may progress. Another one is to suspend sleep; however, Apple says certain events can be suspended at most 30 seconds, after that, the system will just continue, whether your app likes it or not. And finally, you can cancel it; though not all events can be canceled. If the system already decided it will go to sleep, you can only suspend this by at most 30 seconds or allow it at once, you cannot cancel it. However, you can also listen to an event, where the system asks apps, if it is okay to go to sleep now and there you can reply "no", causing a sleep to be canceled.
The difference between "Is it okay to sleep" and "I'm planing on going to sleep" is: The first one is sent if the power saving settings are applied, that is, if the user has not moved the mouse or typed anything for the time configured there. In that case the system will just ask, if sleep is okay. An app like Apple's DVD Player will say "no", because most likely the user watches a DVD and thus doesn't interact with the computer, still no reason to go to sleep. OTOH, if the user closes his Mac Book, apps are not asked, the system will go to sleep for sure and just informs apps, that have now up to 30 seconds to react to it.
Wake-up events can also be quite interesting to catch. E.g. if your system wakes up, open files might be inaccessible (an external drive has been unplugged) or network sockets won't work any longer (network has changed). So you may re-init certain app parts before using them and running into errors that are more or less expected.
Apple's page regarding catching these events.
It depends on your app.
If you are interacting with external systems (think networking or doing something over usb/firewire,etc) then it might be affected. An application running on OSX gets to run for a limited time ( max 10ms ) , after which it is interrupted by the kernel which schedules a new process from the process queue to run on the CPU. This is transparent for the application , which "thinks" that it runs all the time on the CPU. Thus , a transition to sleep is no different - apart from the time jumping ahead.
If you need to be aware that there was a transition to sleep mode please refer to this tech note which details how to receive notifications about the state change : Registering and unregistering for sleep and wake notifications
I believe it will just suspend all apps wherever they happen to be.
Remember, this happens all the time anyway. Applications are constantly suspended and resumed due to context switching. So, really, the clock could jump between any 2 instructions in your app, though usually not in a noticable/significant way.
If the OS waited for the app to return to some main loop you could run into situations where applications cause the sleep to hang. If they're doing a lot of work and not returning to the run loop dispatcher they would prevent the machine from going to sleep. That wouldn't be very good. :)
And if you set the time it also appears to leap forward to the running programs. Nothing special either.
Check out this Wikipedia article. Cavver is correct in stating that things like network connections may time out, and thus those services may be interrupted.