Why does my code crashes?
dispatch_async(queue_A, ^{
#synchronized(self) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[self logInfo:#"queue_A"];
[pool release];
}
});
dispatch_async(queue_B, ^{
#synchronized(self) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[self logInfo:#"queue_B"];
[pool release];
}
});
You're better off avoiding using #syncronized inside dispatch_async, as suggested in the comments. If it's not safe to call [self logInfo:...] then you might want to either:
Use a dispatch group to make sure multiple dispatch_async() calls to a resource don't crash your app. Mike Ash has a good write-up of this technique. Check out his examples.
Use a dispatch semaphore to force separate calls to wait for each other to complete. See the manpage for more.
I'm not sure what logInfo does in this context so you may be able to rewrite that as well.
Solved the problem.
Access to UI has to be via main queue ONLY
Related
I am new to asynchronous callbacks and have been given differing advice. I need to perform asynchronous callbacks and after many hours of research I still do not know if I should use blocks or GCD and queues. Any pointers would be welcome.
OK. So what I was really asking is:
"in order to use an 'asynchronous' callbacks, do I need to use GCD and queues?"
What I am gathering from the answers is that the answer is YES. Definitely GCD and queues inside of blocks.
My confusion stemmed from the fact that I had been given the direction that all I needed was a block, like the code below:
[UIView animateWithDuration:.4f
animations:^{
flashView.alpha = 0.f;
}
completion:^(BOOL finished){
[flashView removeFromSuperview];
}
];
But what I am seeing in the answers here is that the above block in not sufficient for making 'asynchronous' callbacks. Instead I DO in-fact need to use GCD and queues inside a block, like the code below:
- (void)invokeAsync:(id (^)(void))asyncBlock resultBlock:(void (^)(id))resultBlock errorBlock:(void (^)(id))errorBlock {
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(queue, ^{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
id result = nil;
id error = nil;
#try {
result = asyncBlock();
} #catch (NSException *exception) {
NSLog(#"caught exception: %#", exception);
error = exception;
}
// tell the main thread
dispatch_async(dispatch_get_main_queue(), ^{
NSAutoreleasePool *secondaryPool = [[NSAutoreleasePool alloc] init];
if (error != nil) {
errorBlock(error);
} else {
resultBlock(result);
}
[secondaryPool release];
});
[pool release];
});
}
An asynchronous callback is one where your current thread keeps executing statements, and you detach the execution of code in a different thread to be ran later.
There are several technologies to accomplish this. On this example I'm calling the method cacheImage:, with parameter image (just an example) in 4 different asynchronous ways.
// 1. NSThread
[NSThread detachNewThreadSelector:#selector(cacheImage:) toTarget:self withObject:image];
// 2. performSelector...
[self performSelectorInBackground:#selector(cacheImage:) withObject:image];
// 3. NSOperationQueue
NSInvocationOperation *invOperation = [[NSInvocationOperation alloc] initWithTarget:self selector:#selector(cacheImage:) object:image];
NSOperationQueue *opQueue = [[NSOperationQueue alloc] init];
[opQueue addOperation:invOperation];
// 4. GCD
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[self cacheImage:image];
});
By far the more simple way is to use GCD because it already has a thread ready for you to use, instead having to create it yourself with the other options.
However, because blocks are implemented as objects, you could indeed use blocks without GCD, for example:
// block definition
typedef void (^hello_t)();
// method that uses a block as parameter
-(void) runBlock:(hello_t)hello {
hello();
}
// asynchronous execution of a block
[NSThread detachNewThreadSelector:#selector(runBlock) toTarget:self withObject:^(){
NSLog(#"hi");
}];
PS: you don't need to use NSAutoreleasePool manually unless you create many many objects and you want to free memory immediately. Also, #try #catch are rarely used in Objective-C
Not any point of confusion here. GCD also has a block execution.
GCD API, which supports the asynchronous execution of operations at the Unix level of the system.
Block objects are a C-level syntactic and runtime feature. They are similar to standard C functions, but in addition to executable code they may also contain variable bindings to automatic (stack) or managed (heap) memory. A block can therefore maintain a set of state (data) that it can use to impact behavior when executed.
Apple designed blocks with the explicit goal of making it easier to write programs for the Grand Central Dispatch threading architecture, although it is independent of that architecture and can be used in much the same way as closures in other languages. Apple has implemented blocks both in their own branch of the GNU Compiler Collection and in the Clang LLVM compiler front end. Language runtime library support for blocks is also available as part of the LLVM project.
Therefore you can use any one of them given you same functionality.
In Apple's MVCNetworking sample code, the NetworkManager class includes this method to maintain a run loop in a secondary thread dedicated to network activity (in order to run NSURLConnection asynchronously):
- (void)networkRunLoopThreadEntry
{
while(YES) {
NSAutoreleasePool *pool;
pool = [[NSAutorelease alloc] init];
[[NSRunLoop currentRunLoop] run];
[pool drain];
}
}
Since the run method exits immediately if there is no source attached to the run loop, this looks like an infinite while loop which is going uselessly to consume CPU resources if there is currently no NSURLConnection attached to the run loop.
On the other hand, to keep the run loop active, some suggests to schedule an empty port in the run loop:
- (void)networkRunLoopThreadEntry
{
NSAutoreleasePool *pool = [[NSAutorelease alloc] init];
NSPort *port = [NSPort port];
[[NSRunLoop currentRunLoop] addPort:port forMode:NSRunLoopCommonModes];
[NSRunLoop run];
[pool drain];
}
However, in this case, my worry is that the run method will never exit, which means the pool will never get drained, which means all objects allocated and autoreleased in the secondary thread will leak.
What is the way to go then?
(For the context, as many others, I'm trying to encapsulate an asynchronous NSURLConnection inside a NSOperation, which means it can be triggered outside of the main thread. Also, the MVCNetworking sample code, as well as the WWDC 2010 sessions Network Apps for iPhone OS, seem to suggest it is a good idea to have a unique secondary thread dedicated to network transfers to prevent latency on the main thread.)
You can create a CFRunLoopObserver for the kCFRunLoopBeforeWaiting activity and add it to the run loop. In the observer's callout, release the old pool and create a new one. Untested example:
static void resetPoolCallout(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {
NSAutoreleasePool **poolPointer = (NSAutoreleasePool **)info;
[*poolPointer release];
*poolPointer = [[NSAutoreleasePool alloc] init];
}
- (void)networkRunLoopThreadEntry {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSPort *port = [NSPort port];
[[NSRunLoop currentRunLoop] addPort:port forMode:NSRunLoopCommonModes];
CFRunLoopObserverContext observerContext = {
.version = 0,
.info = (void*)&pool,
.retain = NULL,
.release = NULL,
.copyDescription = NULL
};
CFRunLoopObserverRef observer = CFRunLoopObserverCreate(NULL, kCFRunLoopBeforeWaiting,
true, 0, resetPoolCallout, &observerContext);
CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopCommonModes);
[[NSRunLoop currentRunLoop] run];
CFRunLoopRemoveObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopCommonModes);
CFRelease(observer);
[pool release];
}
I currently have a shell script that process many images one after the other, with the help of GraphicsMagick. It works fine, all calculations are correct, everything works. (that's not a "simple" script, it involves reading dimensions from a JSON file, converting a bunch of images with respect to many constraints).
As we're working with dual-core or quad-core computer, I'd like to parallelize it. And as I'm an iPhone developer liking to introduce myself to Mac development, I'd like to create it with XCode and Objective-C using the "command-line tool" template.
So far so good, but now I'm face with the design of the "task dispatcher" object. I'm fairly lost between running NSTasks in a run loop, in separate threads, using blocks, with or without GCD, with or without ARC.
How would one achieve this? I was thinking of using simple threads to spawn NSTasks, having them report when they're done, and notify my dispatcher's delegate so that it can upgrade its progress bar. But I'd really like to get in touch with Grand Central Dispatch. Does anyone have any thoughts, ideas, advice about what to do and what not?
Edit: I'm reading Apple's docs, and have found the NSOperationQueue class. Could it be that this is precisely what I'm needing here?
A good class to use to launch independant processes including parameters and environment variables is NSTask. See the documentation for the gory details. Here is a little commandline tool that starts 10 concurrent processes and waits for them to finish. NSOperationQueue would be redundant here because the tasks are already launched concurrently.
-- Edit: Improved Version With Limited Concurrency --
int main (int argc, const char * argv[])
{
#autoreleasepool {
// Let's not have more than 5 parallel processes
dispatch_semaphore_t limit = dispatch_semaphore_create(5);
dispatch_semaphore_t done = dispatch_semaphore_create(0);
for (int i=0; i<10; i++) {
// Setup the taks as you see fit including the environment variables.
// See docs on NSTask for more on how to use this object.
NSTask *task = [[NSTask alloc] init];
task.launchPath = #"/bin/ls";
task.arguments = [NSArray arrayWithObject:#"-la"];
task.terminationHandler = ^(NSTask *task) {
dispatch_semaphore_signal(limit);
if (i==9) dispatch_semaphore_signal(done);
};
dispatch_semaphore_wait(limit, DISPATCH_TIME_FOREVER);
[task launch];
}
dispatch_semaphore_wait(done, DISPATCH_TIME_FOREVER);
dispatch_release(limit);
dispatch_release(done);
}
return 0;
}
-- Original Version --
int main (int argc, const char * argv[])
{
#autoreleasepool {
NSObject *lock = [[NSObject alloc] init];
int __block counter = 10;
for (int i=0; i<10; i++) {
// Setup the taks as you see fit including the environment variables.
// See docs on NSTask for more on how to use this object.
NSTask *task = [[NSTask alloc] init];
task.launchPath = #"/bin/ls";
task.arguments = [NSArray arrayWithObject:#"-la"];
task.terminationHandler = ^(NSTask *task) {
#synchronized(lock) { counter--; }
};
[task launch];
}
while (counter)
usleep(50);
[lock release];
}
return 0;
}
In your case you might want to hold the NSTask objects in an array for easier management.
yes - NSOperation/NSOperationQueue are good for this task.
i'd start with something like this:
#protocol MONTaskRequestDelegate
- (void)taskRequestDidComplete:(MONTaskRequest *)taskRequest;
#end
#interface MONTaskRequest : NSOperation
{
#private
NSTask * task;
NSObject<MONTaskRequestDelegate>* delegate; /* strong reference. cleared on cancellation and completion, */
}
- (id)initWithTask:(NSTask *)task delegate:(NSObject<MONTaskRequestDelegate>*)delegate;
// interface to access the data from the task you are interested in, whether the task completed, etc.
#end
#implementation MONTaskRequest
// ...
- (void)performDelegateCallback
{
[self.delegate taskRequestDidComplete:self];
self.delegate = nil;
}
- (void)main
{
NSAutoreleasePool * pool = [NSAutoreleasePool new];
[self runTheTask];
// grab what is needed and handle errors
[self performDelegateCallback];
[pool release];
}
- (void)cancel
{
[super cancel];
[self stopTaskIfPossible];
[self performDelegateCallback];
}
#end
then you can use NSOperationQueue to limit the number of active tasks to a reasonable number.
I use for this purpose the [myObj performSelectorInBackground:#selector(doSomething) withObject:nil]; functionality of an NSObject.
The idea is quite simple: you write a method that does the work, call it from the main thread using the aforementioned method, then call some callback selector if you need to somehow process the results from different threads.
I'm trying to create a thread that configures a run loop to run a physics engine through a defined NSTimer. However, I'm having trouble making the thread exit normally (or I think the problem is).
Attached are the relevant portions of my code:
(This code is in a view controller)
(back is called when a button is pressed)
- (void)back {
[timestep invalidate];
exiting = YES;
[self release];
}
- (void)initializePhysicsWorld {
// Initializes the thread to simulate physics interactions.
[NSThread detachNewThreadSelector:#selector(physicsThreadMethod)
toTarget:self
withObject:nil];
}
- (void)physicsThreadMethod {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSRunLoop *myRunLoop = [NSRunLoop currentRunLoop];
timestep = [NSTimer timerWithTimeInterval:1.0f/60.0f
target:self
selector:#selector(step:)
userInfo:nil
repeats:YES];
[myRunLoop addTimer:timestep forMode:NSDefaultRunLoopMode];
while (!exiting) {
CFRunLoopRun();
[pool release];
pool = [[NSAutoreleasePool alloc] init]; // periodically refreshes pool
}
CFRunLoopStop([myRunLoop getCFRunLoop]);
NSLog(#"Thread is going to exit");
[pool release];
}
- (void)dealloc {
if ([self.view superview]) {
[self.view removeFromSuperview];
}
[super dealloc];
}
The engine (the step: function) runs fine, but when I try to exit the loop by running the method back, it would appear that the thread does not release its retain on my view controller (dealloc is not called). I think my thread didn't exit the physicsThreadMethod method as the NSLog does not appear in the console. Dealloc was only called when I run 'back' a second time.
I'm not really sure why this is happening, so I would really appreciate any help. Thanks!
The problem lies in here:
while (!exiting) {
CFRunLoopRun(); //<-- here you start the run loop.
// the lines under this line are NEVER executed. also the while loop does nothing
[pool release];
pool = [[NSAutoreleasePool alloc] init]; // periodically refreshes pool
}
You could use NSOperations to wrap your work, there are already properties defined on this class to do exactly this kind of thing.
If you want to stick with your implementation in a NSThread you have to take a look at the CFRunLoop reference and how to add observers to the run loop.
Does CFRunLoopRun return every step:? CFRunLoopStop or [myRunLoop runUntilDate:] would help.
So, I am using [NSThread detachNewThreadSelector] to spawn a new thread and I am getting "autoreleased with no pool in place " errors in the console. I know this can happen if you fail to create an auto release pool, but the thing is, I am creating one. I use similar code in other parts of the same app and do NOT get these errors.
Here is the relevant code:
- (void) startThread:(NSString*)strURL
{
// start new thread to load image
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[NSThread detachNewThreadSelector:#selector(loadImageFromURL:) toTarget:self withObject:strURL];
[pool release];
}
- (void) loadImageFromURL:(NSString*)strURL
{
NSNumber* nn = [NSNumber numberWithInt:self.tag];
NSLog(#"loadURL: Tag number == %i", [nn intValue]);
// other code here actually does the work
}
Now, there was more code in loadImageFromURL which actually does the work (of loading an image from a remote server) - but the problem manifests itself without that code, so I've removed it (just so you don't think I have a pointless thread which does nothing!). I left in just one line of code which demonstrates the problem - it creates an autoreleased NSNumber object.
When this code runs, it reports this to the console:
__NSAutoreleaseNoPool(): Object 0x535c0e0 of class NSCFNumber autoreleased with no pool in place - just leaking
Of course, the real code creates many other AR objects and all of them get reported as well.
Would be grateful for any tips or pointers which might help!
Thanks!
When you create a new thread, you need to also create a new autorelease pool for it. In your case, that looks as simple as adding:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
at the beginning of loadImageFromURL: and
[pool drain];
at the end.
You probably don't need or want the pool you're creating in startThread:. Check out the Threading Programming Guide, particularly the "Writing Your Thread Entry Routine" section.
On your code, - (void) startThread:(NSString*)strURL is running in the main thread, while - (void) loadImageFromURL:(NSString*)strURL is running on the background thread you are detaching.
The main thread already has a NSAutoreleasePool, so the one you are creating in startThread: is probably unneeded. However, the background thread will not create a NSAutoreleasePool, so you'd need to create it yourself.
In your code, that would look like:
- (void) startThread:(NSString*)strURL
{
// start new thread to load image
[NSThread detachNewThreadSelector:#selector(loadImageFromURL:) toTarget:self withObject:strURL];
}
- (void) loadImageFromURL:(NSString*)strURL
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSNumber* nn = [NSNumber numberWithInt:self.tag];
NSLog(#"loadURL: Tag number == %i", [nn intValue]);
// other code here actually does the work
[pool drain];
}
Also, as #Carl Norum suggested, you should use drain instead of release when you are done using the autorelelase pool.
Solution for a similar problem but using ARC.
If using ARC, you could get an error "'NSAutoreleasePool' is unavailable: not available in automatic reference counting mode".
Use:
- (void) startThread:(NSString*)strURL
{
// start new thread to load image
[NSThread detachNewThreadSelector:#selector(loadImageFromURL:) toTarget:self withObject:strURL];
}
- (void) loadImageFromURL:(NSString*)strURL
{
#autoreleasepool {
NSNumber* nn = [NSNumber numberWithInt:self.tag];
NSLog(#"loadURL: Tag number == %i", [nn intValue]);
// other code here actually does the work
}
}