Suppose I have a thread inside my application that repeatedly sleeps for x number of seconds until woken up repeatedly by interrupts coming from activity it is monitoring.
Now the number of times it enters sleep can be very large like 50-100 times. And the time it sleeps everytime can be substantial like 20 secs.
So for this thread to come out of this waiting loop, it takes large amount of times thereby inhibiting my ability to debug.
What I would like to ideally do is for me to make Eclipse debugger manually throw InterruptException so that I can wake up the thread much faster each time it enters sleep.
Is this possible with Eclipse debugger?
Related
I'm trying to set up a simple OpenGL game on macOS, using an NSTimer to set up a run loop as explained here. The idea is to create a repeating timer with a very small (~1ms) time interval and rely on vsync to regulate the frame rate.
I'm setting my NSOpenGLContext swap interval to a value of 1, which should enable vsync. I was under the impression that this would cause NSOpenGLContext.flushbuffer to block, but this doesn't seem to be the case. My render code is firing off much more frequently than 60 times per second.
The document I linked has been marked as retired, but all the official documentation I've read suggests that it's possible to throttle an NSTimer loop to the display's refresh rate somehow. I haven't been able to get this working though, and I'm wondering if this approach is no longer viable.
Am I missing something? In a modern project, is it better just to go with a CVDisplayLink?
My understanding is that it's unlikely that an NSTimer will fire more frequently than about 10-20 times per second, and with timer coalescing you aren't likely to get guaranteed fire times appropriate for this type of application. For example, one answer to this question points out that the docs say:
Because of the various input sources a typical run loop manages, the effective resolution of the time interval for a timer is limited to on the order of 50-100 milliseconds. If a timer’s firing time occurs during a long callout or while the run loop is in a mode that is not monitoring the timer, the timer does not fire until the next time the run loop checks the timer. Therefore, the actual time at which the timer fires potentially can be a significant period of time after the scheduled firing time.
CVDisplayLink is definitely the preferred solution. It's quite simple to use, too.
And to answer your other question, yes something has changed. The OS has changed how timers are handled to help improve energy performance. I worked on an app that used the method you're suggesting up until about OS 10.9 or 10.10. Once that came out we had to rethink our strategy because timers worked differently.
When launching my app from a custom URL scheme, when app is not backgrounded, the launch sequence is taking longer then I would like. I want to use time profiler to see what methods are taking so long. I know on run there is an option for "Wait for App Launch" so I can launch it using the URL, but I don't see that under the profiling scheme. Does anyone know a way that I can launch the app fresh, using the URL, and have time profiler running on launch?
"see what methods are taking so long"
Do you suppose some method (or a few) are sopping up a lot of CPU time in themselves or by calling other methods that do?
If so, it will be easy to fix, but it's Not Likely.
More likely the time is spent in I/O of one sort or another, and you need to figure out why, not where.
If you're able to start it under a debugger (say by using #ChrisTruman's recommendation), then all you need to do is interrupt it with Ctrl-C, Ctrl-Break, Escape, or whatever key combination interrupts it.
Do this during the time when, subjectively, it is slow.
Let's suppose the startup is taking three times longer than you think it should.
If that's so, that means two thirds of the time is spent doing the unnecessary I/O or whatever it is.
That means each time you interrupt it, the probability is 2/3 that you will catch it in the act of doing whatever causes the slowness.
So interrupt it a few times, and each time just read the stack, look at variables, etc.
You will see why it's being slow.
Don't even look for where - that will appear by itself.
That's the basic idea behind this technique.
I am trying to figure out how to use a background thread to execute a command ever 4hrs.
I have never created anything like this before so have only been reading about it so far.. One of the things I have read are this
"Threads tie up physical memory and critical system resources"
So in that case would it be a bad idead to have this thread that checkes the time then executes my method... or is there a better option, I have read about GCD (Grand Central Dispatch) but I am not sure if this is applicable as I think its more for concurrent requests? not something that repeats over and over again checking the time..
Or finally is there something I have completely missed where you can execute a request every 4hrs?
Any help would be greatly appreciated.
There is a max time background processes are allowed to run (10 min) which would make your approach difficult. Your next best attempt is to calculate the next event as save the times tamp somewhere. Then if the app is executed at or after that event it can carry out whatever action you want.
This might help:
http://www.audacious-software.com/2011/01/ios-background-processing-limits/
I think that it would be good to make use of a time stamp and post a notification for when the time reaches for hours from now.
Multithreading is not a good means to do this because essentially you would be running a loop for four hours eating clock cycles. Thanks to the magic of operating systems this would not eat up an entire core or anything silly like that however it would be continuously computed if it was allowed to run. This would be a vast waste of resources so it is not allowed. GCD was not really meant for this kind of thing. It was meant to allow for concurrency to smooth out UI interaction as well as complete tasks more efficiently, a 4hr loop would be inefficent. Think of concurrency as a tool for something like being able to interact with a table while its content is being loaded or changed. GCD blocks make this very easy when used correctly. GCD and other multithreading abilities give tools to do calculations in the background as well as interact with databases and deal with requests without ever affecting the users experience. Many people whom are much smarter then me have written exstensively on what multithreading/multitasking is and what it is good for. In a way posting a message for a time would be method of multitasking without the nastiness of constantly executing blocks through GCD to wait for the 4 hr time period, however it is possible to do this. You could execute a block that monitored for time less then the max length of a threads lifetime then when the threads execution is over dispatch it again until the desired time is achieved. This is a bad way of doing this. Post a notification to the notification center, its easy and will accomplish your goal without having to deal with the complexity of multithreading yourself.
You can post a notification request observing for a time change and it will return its note, however this requires you application be active or in the background. I can not guarantee the OS wont kill your application however if it is nice and quiet with a small memory footprint in "background" state its notification center request will remain active and function as intended.
I was reading a book which says that a processor with single core and no hyper-threading can process only one process at a time, so a doubt arises that when we do so many operations on a PC and also some background processes are always there then why not music player stops in between for short while. I know the CPU is pretty fast but still music player usually plays music in continuance without any small break ( that is observable ). Can anyone clarify this behavior?
1) A single-core CPU without hyperthreading can, as you say, only run one process at a time. Multiple processes are handled by context-switching, that is the CPU will run one process and then switch to the next process and the next and then back to the first process and so on. The frequency of how often a certain process is scheduled is dependent on lots of different factors, where process priority is one. (Back in the days it was often needed to run WinAmp with elevated priority to avoid glitches etc. Nowadays this is not needed as the CPU is a lot faster).
2) So, with this in mind, how come it still sounds great and without glitches?
When processing audio the CPU feeds the sound device with samples by putting them either in a hardware buffer on the sound card or in the RAM. The sound processor does not get its data directly from the CPU, instead it reads the samples from one of these two buffers. As long as we have samples in the buffer we are good, even though the CPU is off doing something else.
The details about the hardware buffer size is different on different sound cards. Some (older) sound cards does not have a sound buffer at all, and here the RAM comes into play instead.
Running out of samples is called buffer underrun. Even on modern computers this can happen, for example if you start a heavy process while running your audio player the CPU may not be able to switch back in time and we can clearly hear glitches and gaps in the sound feed.
This is due to an operating system which does preemptive multi-tasking. The process is in fact being interrupted for a very short amount of time, not long enough to notice for a human. Another reason is also that the audio card has a playback buffer which allows the playback continously, while data is being fed to it in chunks. So while the process of feeding the card with data is being interrupted for a very short time, the playback can still occur.
This is handled by the Operating System Scheduler.
The scheduler will allocate a time slice to each process (this maybe a few milliseconds) and will allow a process to execute what it needs to for that length of time. The length allocated is determined by the algorithm used by the OS (I.e. Short term scheduling, long term etc). The reason why you do not notice this is because the CPU can operate at such high frquencies, i.e. 1GHz which makes multi tasking on a single core / thread transparent to the user.
http://en.wikipedia.org/wiki/Scheduling_(computing)
http://web.cs.wpi.edu/~cs3013/c07/lectures/Section05-Scheduling.pdf
Currently i am following thread to check wheather my internet is active or not in my application, but as it is taking time to give the response ,so this will freeze my UI.
So is there any way to implement it without freezing UI(like NSOperation).
If the internet is indeed down, it takes time. It is limitation of Apple's API. We have to live with it or put a timer to cancel the operation after 30 secs or so. But if a genuine response especially via GPRS takes more than 30 secs, you will be canceling that too if you put timer condition.
Alternatively, you could check for internet status asynchronously and display an ActivityIndicator or similar in the main thread. This means that you create a new thread which will run parallel with your main thread (in your case, the GUI that are freezing).