macOS detachNewThreadSelector return result?

[BollywooD]

I need to move some string comparisons into a new thread, but are not quite sure how to go about getting the results of the comparison back into my method....

is there an easy way to do this?
**I am checking potentially hundreds of strings at any giving time

here is some of the code I am using (simplified):

- (NSURLRequest*) checkImageRequest: (NSURLRequest*) request{	
	NSURL* domain = [request mainDocumentURL];	
	
	int matched = [self matchURL:[theDomain absoluteString]];
	if (matched == isUserWhiteListed)
	{
		return request;
	}
}

and the matchURL method:

- (int)matchURL:(NSString*)theURL
{	
	int matchResult = [sab_filterSet matchToString:urlCString];
	if (matchResult == isWhiteListed)
	{
		return isWhiteListed;
	}
}

I want to send the matchURL method into it's own thread. and receive the result back in the checkImageRequest method

 

[Sydde]

You should expect the method that generates the thread to exit and the results to appear asynchronously. In other words, your detached thread will return results when it does, while your main program goes on to whatever else it might be doing. If you need to do UI stuff on behalf of the thread, perhaps the best way to do this is the performSelectorOnMainThread method whenever your thread needs its results displayed. Otherwise, you can more or less visualize your thread as an independent program doing its own thing.

Bear in mind, also, that hundreds of comparisons can generally be done in milliseconds or less. Be absolutely certain that you need to thread your program before taking that course

 

[gnasher729]

1. It is natural to assume that using NSThreads is documented in the NSThreads documentation, but a lot of very important methods are actually in NSObject; for example performSelectorInBackground. Read the NSObject documentation.

2. If your application is intended for 10.6 only, look at Grand Central Dispatch. GCD + blocks can make your life a lot, lot easier.

3. When you use threads to do things in the background and keep the UI responsive, you'll need to change your programming style. You tell the OS to run a method in a background thread. Don't even think about getting a return value. When the method finishes, the last thing it does is call performSelectorOnMainThread, which calls a selector that can process the results. So the principle is that you shoot off a method, which will be handled in the background, and at some time later another method is called in your main thread that delivers results.

4. It may happen that at the time the result is delivered, it isn't needed anymore. Lets say the user can open a directory, then you start a thread that gets a list of all JPEG images in that directory, by the time the thread finishes the user might have switched to another directory. You'll need to handle this.

5. Be careful with autoreleased objects. Autorelease pools are per thread. If performSelectorOnMainThread uses an autoreleased object then that object may disappear at any time. No fun.

 

[BollywooD]

Im going to put this in the too hard basket for the time being, and come back to it in the future...



It's not critical, but I thought it may provide some speed boosts. I did manage to optimise code elsewhere though.



Thanks for the help guys.