I bought the Big Nerd Ranch Guide for Objective-C, and there is something about NSRunLoop I can't figure out.
Here's a chunk of code from the book:
NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:2.0
target:logger
selector:#selector(updateLastTime:)
userInfo:nil
repeats:YES];
[[NSRunLoop currentRunLoop] run];
My question is, why do I need to put an NSRunLoop for the NSTimer object to be processed? And why does it need to be at the end, and not the beginning?
Why it is not like the other functions or object's methods where I simply have to call a function for it to be processed and logged into the console?
I'm really trying figure out every logic of every detail here.
From the early days of what would become Cocoa, when dinosaurs roamed the Earth, rocks were soft, and NeXT workstations were new, up until 10.6 came out, the most common type of multitasking was the run loop. It's cooperative multitasking. There are no threads. There is no preemptive scheduler or kernel. There are no context switches. There's just a big run loop that says "what needs doing now?" and runs it. And when that thing completes, it waits for the next thing that needs doing and runs that. It literally is a big while(true) loop. Well, technically the line of code is:
for (;;) { ... }
You can see for yourself in CFRunLoop.c. Look for __CFRunLoopRun.
NSTimer was invented in those days. All it does it make a note in the runloop telling it "when this time passes, then please do this." (It's a tiny bit more complicated than that because it uses mach ports, look for __CFRunLoopTimerSchedule in the same file for details, but basically that's the idea.)
So the point is, there's no magic. There's just a big for(;;) loop that processes this stuff. Something has to run it. And when you start it (with run), it doesn't return. It's an infinite loop. There is no "background." There are no other threads. And that's why you need to do things in the order BNR tells you to. Otherwise your next line of code wouldn't run.
Of course in iOS apps and OS X GUI apps, you don't usually have to do this yourself. The run loop gets created for you during program startup, and the whole main thread lives inside of it. It's the thing that calls you most of the time. You don't call it. But if you're on a thread other than the main thread, and you want to use run loop functionality, you're going to have to run it yourself.
Today, a lot of things are done with GCD rather than run loops. That's the "until 10.6 came out" that I mentioned. It really changed the Cocoa world. But a huge amount of Cocoa still relies on the run loop, and it's still the workhorse of most apps even if you never think about it.
In most cases today, if you're having to create a runloop in order to use NSTimer, you shouldn't be using NSTimer. Just use dispatch_after. In fact, that's what I usually recommend most of the time today even if you do have a runloop.
(And you should definitely read the link #quelish gives in the comments. It is the definitive word on run loops.)
Related
I have written a compiler and interpreter for a scripting language. The interpreter is a DLL ('The Engine') which runs in a single thread and can load many 100s or 1000s of compiled byte-code applications and excecute them as a set of internal processes. There is a main loop that excecutes a few instructions from each of the loaded app processes before moving one to the next process.
The byte code instruction in the compiled apps can either be a low level instructions (pop, push, add, sub etc) or a call to an external function library (which is where most of the work is done). These external libararies can call back to the engine to put the internal processes into a sleep state waiting for a particular event upon which the external function (probably after receiving an event) will wake up the internal process again. If all internal processes are in a sleep state (which the are most of the time) then I can put the Engine to sleep as well thus handing off the CPU to other threads.
However there is nothing to prevent someone writing a script which just does a tight loop like this:
while(1)
x=1;
endwhile
Which means my main loop will never enter a sleep state and so the CPU goes up to 100% and locks up the system. I want my engine to run as fast as possibly, whilst still handling windows events so that other applications are still responsive when a tight loop similar to the above is encountered.
So my first question is how to add code to my main loop to ensure windows events are handled without slowing down the main engine which should run at the fastest speed possible..
Also it would be nice to be able to set the maximum CPU usage my engine can use and throttle down the CPU usage by calling the occasional Sleep(1)..
So my second question is how can I throttle down then CPU usage to the required level?
The engine is written in Borland C++ and makes calls to the win32 API.
Thanks in advance
1. Running a message loop at the same time as running your script
I want my engine to run as fast as
possibly, whilst still handling
windows events so that other
applications are still responsive when
a tight loop similar to the above is
encountered.
The best way to continue running a message loop while performing another operation is to move that other operation to another thread. In other words, move your script interpreter to a second thread and communicate with it from your main UI thread, which runs the message loop.
When you say Borland C++, I assume you're using C++ Builder? In this situation, the main thread is the only one that interacts with the UI, and its message loop is run via Application->Run. If you're periodically calling Application->ProcessMessages in your library callbacks, that's reentrant and can cause problems. Don't do it.
One comment to your question suggested moving each script instance to a separate thread. This would be ideal. However, beware of issues with the DLLs the scripts call if they keep state - DLLs are loaded per-process, not per-thread, so if they keep state you may encounter threading issues. For the moment purely to address your current question, I'd suggest moving all your script execution to a single other thread.
You can communicate between threads many ways, such as by posting messages between them using PostMessage or PostThreadMessage. Since you're using Borland C++, you should have access to the VCL. It has a good thread wrapper class called TThread. Derive from this and put your script loop in Execute. You can use Synchronize (blocks waiting) or Queue (doesn't block; method may be run at any time, when the target thread processes its message loop) to run methods in the context of another thread.
As a side note:
so that other
applications are still responsive when
a tight loop similar to the above is
encountered.
This is odd. In a modern, preemptively multitasked version of Windows other applications should still be responsive even when your program is very busy. Are you doing anything odd with your thread priorities, or are you using a lot of memory so that other applications are paged out?
2. Handling an infinite loop in a script
You write:
there is nothing to prevent someone
writing a script which just does a
tight loop like this:
while(1) x=1; endwhile
Which means my main loop will never
enter a sleep state and so the CPU
goes up to 100% and locks up the
system.
but phrase how to handle this as:
Also it would be nice to be able to
set the maximum CPU usage my engine
can use and throttle down the CPU
usage by calling the occasional
Sleep(1)..
So my second question is how can I
throttle down then CPU usage to the
required level?
I think you're taking the wrong approach. An infinite loop like while(1) x=1; endwhile is a bug in the script, but it should not take down your host application. Just throttling the CPU won't make your application able to handle the situation. (And using lots of CPU isn't necessarily a problem: if it the work is available for the CPU to run, do it! There's nothing holy about using only a bit of your computer's CPU. It's there to use after all.) What (I think) you really want is to be able to continue to have your application able to respond when running this script (solved by a second thread) and then:
Detect when a script is 'not responding', or not calling into your callbacks
Be able to take action, such as asking the user if they want to terminate the script
An example of another program that does this is Firefox. If you go to a page with a misbehaving script, eventually you'll get a dialog asking if you want to stop the script running.
Without knowing more about how your script is actually interpreted or run, I can't give a detailed answer to these two. But I can suggest an approach, which is:
Your interpreter probably runs a loop, getting the next instruction and executing it. Your interactivity is currently provided by a callback running from one of those instructions being executed. I'd suggest making use of that by having your callback simply log the time it was last called. Then in your processing thread, every instruction (or every ten or a hundred) check the current time against the last callback time. If a long time has passed, say fifteen or thirty seconds, it may be an indication that the script is stuck. Notify the main thread but keep processing.
For "time", something like GetTickCount is probably sufficient.
Next step: Your main UI thread can react to this by asking the user what to do. If they want to terminate the script, communicate with the script thread to set a flag. In your script processing loop, again every instruction (or hundred) check for this flag, and if it's set, stop.
When you move to having one thread per script interpreter, you TThread's Terminated flag for this. Idiomatically for something that runs infinitely in a thread, you run in a while (!Terminated && [any other conditions]) loop in your Execute function.
To actually answer your question about using less CPU, the best approach is probably to change your thread's priority using SetThreadPriority to a lower priority, such as THREAD_PRIORITY_BELOW_NORMAL. It will still run if nothing else needs to run. This will affect your script's performance. Another approach is to use Sleep as you suggest, but this really is artificial. Perhaps SwitchToThread is slightly better - it yields to another thread the OS chooses. Personally, I think the CPU is there to use, and if you solve the problem of an interactive UI and handling out-of-control scripts then there should be no problem with using all CPU if your script needs it. If you're using "too much" CPU, perhaps the interpreter itself could be optimised. You'll need to run a profiler and find out where the CPU time is being spent.
Although a badly designed script might put you in a do-nothing loop, don't worry about it. Windows is designed to handle this kind of thing, and won't let your program take more than its fair share of the CPU. If it does manage to get 100%, it's only because nothing else wants to run.
I'm trying to build a super-simple Cocoa app, basically one that has one function (for example, main()) with a while loop. It does some stuff, does a curl request, then waits a few seconds before starting over.
I've got my project all setup in XCode with all the necessary variables and functions, but I don't know where to put my main() function that does all the work.
Where do I define the main function?
Cocoa is very much oriented towards event-driven programming. That end, the main() function generally just starts up the main runloop and then the application delegate can kick off anything it wants to do. That said, it's certainly possible to write a non-event-based cocoa program that uses main() To do more complicated stuff. In that case, it works basically the same as in C.
Cocoa With Love just had a post about Minimalist Cocoa programming that may be of interest. It uses main() to do some work. It's not really something I would recommend emulating in your own app, but it's certainly possible.
If you design your app according to the usual Cocoa architecture, you don't really put any of your own code in main. The whole app should be event driven (where events are things like UI interactions from the user, network events, etc).
That said, there is a main function. If you've created a default Cocoa project in XCode, the main function will be in a file called "main.m". It will get run just like a main function in C. You'll see that there's a call in there to NSApplicationMain(). That's what starts a Cocoa application running (creates the application, loads the main nib file, starts running the main run loop, etc) . NSApplicationMain() doesn't return until the application quits, so if you really want to put stuff in main(), you need to put it above the call to NSApplicationMain().
Again, that's not the normal "Cocoa way" to do things, but without more info about what you want to do, it's hard to give you more advice.
As others have answered, it's possible to implement what you want to do in a way you suggested, i.e., by running a while loop inside main.
However, that is not the best way to write a Cocoa app which reloads a URL once in a few seconds. In a different environment, there's a different standard way to do things. So, you sometimes need to un-learn what you got used to. You might have thought: I want to do X. In language/environment A, I would have coded like P to do X. Now I'd like to use language/environment B. How should I implement P? That's not the way to get used to a new environment. Just ask, How should I do X in the environment B?
The most Cocoa-esque way would be this:
Open XCode, create a new project, choose a Cocoa GUI app from the template.
In the application delegate, implement applicationDidFinishLaunching:. We are going to set up an NSTimer.
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
NSTimer*timer=[NSTimer scheduledTimerWithTimeInterval:5
target:self
selector:#selector(timerFired:)
userInfo:nil
repeats:YES];
}
This creates a timer which fires once in five seconds, and at each time it fires it calls the method timerFired: of the app delegate itself, specified by self. For more on NSTimer, read this apple document.
Implement timerFired:.
- (void)timerFired:(NSTimer*)theTimer{
// do whatever you want. you can use plain C to invoke curl,
// or if you want you can use Cocoa methods to access a URL.
}
There's no fourth step!
The main function is provided by the template. It calls NSApplicationMain, which set up the Cocoa system. Eventually, it calls applicationDidFinishLaunching: of your delegate for you. You respond to that message. Then you set up a timer. The timer calls the method you specified for you. Then you respond to that message, again. That's basically how Cocoa works. The Cocoa system asks you to do something, so you do something. Your control over the flow of the program becomes rather passive, compared to what you would have programmed in Applescript.
To add to Andrew Madsen's answer, the best thing to do is start with an Xcode project template. It'll get a skeletal main(), a XIB, a plist, and other standard Cocoa stuff set up for you.
Is anyone aware of a way to receive NSURLDownload's delegate methods on a separate thread, i.e. not the main one? I am using an NSOperationQueue to manage them but at the moment I need to use the performSelectorOnMainThread method to get it too work. The problem with this is that it drives the kernel task crazy reaching about 30% of CPU cycles. Curiously this has only happened since upgrading to SL, when NSOperationQueue changed behaviour (not that I am dissing it, GCD rocks!)
Thanks
Colin
My first question is, what are you using NSURLDownload to do? Are you just downloading a bunch of files to the disk, or do you really want the data in memory?
If you're downloading a bunch of files to the disk and you don't want to do any special processing, I'd first try just firing off all the NSURLDownloads on the main thread, without bothering with an NSOperationQueue... I mean, how many operations are we talking about? Can they all run concurrently? The callbacks on the main thread shouldn't be too much of a problem, unless you are doing something heavyweight when you get notified you got some data, in which case it seems like...
Otherwise, I'd switch to using NSURLConnection. It's specifically documented to call you back on the thread you set it up on, and is more flexible. Of course, it's not as high-level, so if you really want files saved to disk, you're going to have to write the I/O yourself. Shouldn't be a huge hardship - it's like four extra lines of code.
-W
NSOperationQueue changed behaviour because it was buggy. It's seems really solid now but yeah, it has a different personality.
Reference (http://www.mikeash.com/?page=pyblog/dont-use-nsoperationqueue.html)
Can you give more info on your problem? Do you only need to notify when the download is finished? Are you doing many downloads at once?
I am developing a multi-threaded application in Cocoa. The main thread takes values from the user, and when a button is clicked I invoke a secondary thread in which a long calculation takes place. Now from this thread I have to return the output of every step of the calculation to the main thread. I want to periodically send data from one thread to the other. I can't find any simple example that does this. Any ideas?
There are a number of ways to do this, in rough order of complexity (easiest first):
use NSObject's performSelectorOnMainThread:withObject:waitUntilDone: which is pretty self explanatory.
use performSelector:onThread:withObject:waitUntilDone:, which will let you go the other way
use an NSNotification (and NSDistributedNotificationCenter), though you can easily run into a race condition if you're not careful
Use NSPorts to send data back and forth
Check out the doc that Abizer mentioned for details on all of these.
performSelectorOnMainThread:withObject:waitUntilDone: is often the easiest way to update the UI with a background thread's progress. You could also create your own storage area that's safe to access between threads using NSLock or a similar mechanism, or even use distributed objects (which also works between processes or over a network).
Then there's NSOperationQueue and NSOperation which does help a lot to simplify multi-threaded programming, although a lot of programmers have been avoiding it since it can cause a crash in certain circumstances under Leopard.
Have a look at the Apple docs for this.
You may need to create an ADC member account, but this is free
Multi-threaded Cocoa Programs
I'm going back over some crufty code to tidy it up and I see I've been retaining NSTimers returned from scheduledTimerWithTimeInterval:target:selector:userInfo:repeats: and storing them in a field - then releasing and nulling the field when it fires. In some cases I use the timer to send an invalidate message to it later - but in many cases not.
In more recent code I usually just schedule the timer and forget about it. I understand that the constructor method is autoreleasing and the timer is retained by the run loop while it is active - so I don't see any issue with this.
So, just to round out my understanding - is there any other reason I should be holding on to my timers, or is what I am doing now the accepted idiom?
This is all in the context of iPhone code, but I don't believe this is iPhone specific.
I just let the run loop handle the retention, myself - it's the run loop that owns the timer and not me. If you see what I mean.
I'm answering my own question.
I was mostly asking the question because I'd been browsing through the class reference docs and this issue was not really made clear. I've since read the Timer Programming Topics: Using Timers article in the ADC and it covers it pretty well - especially the section on memory management at the end.
According to that what I am doing now (just scheduling, unless I need to be able to call invalidate, or isValid etc) is the right way.