I have some class A. In this class i have a method,
which calls [self performSelectorInBackground:...]. And it starts downloading
some info from internet.
After i tap Home button, then enter the app again, this background method keeps working.
So, if i call this method again, i have bad_access, because background method is already working and i call it twice.
Can i stop performing selector in background of the class A? For example in my applicationDidEnterBackground?
Or can i check, if selector is performing or something?
I found couple things like
[[NSRunLoop currentRunLoop] cancelPerformSelectorsWithTarget:a];
[NSObject cancelPreviousPerformRequestsWithTarget:a selector:#selector(startDownload) object:nil];
But they didn't work for me.
So
my objAppDelegate:
#inteface ObjAppDelegate
{
A *a;
}
#implementation ObjAppDelegate
{
-(void)applicationDidEnterBackground:(UIApplication *)application
{
//or it can be didBecomeActive..
//here. check if background task of class A is running, or just stop it ??
}
}
#implementation A
{
//some timer, or event, etc.
-(void)startDownload
{
[self performSelectorInBackground:#selector(runBackgroundTask) withObject:nil];
}
-(void)runBackgroundTask
{
//some network stuff..
}
}
i did it like this:
threadForDownload = [[NSThread alloc] initWithTarget:self selector:#selector(threadMain:) object:nil];
[threadForDownload start];
[self performSelector:#selector(startDownload) onThread:threadForDownload withObject:nil waitUntilDone:NO];
(void)threadMain:(id)data {
NSAutoreleasePool *pool = [NSAutoreleasePool new];
NSRunLoop *runloop = [NSRunLoop currentRunLoop];
[runloop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
while (YES) {
[runloop runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
}
[pool release];
}
In my startDownload method i look at activity indicator to check, whether
startDownload is already running..
-(void)startDownload
{
if (![[UIApplication sharedApplication] isNetworkActivityIndicatorVisible]) // flag..
{
//....
}
}
// I make visible networkActivityIndicator every time i start downloading
You can easily create a BOOL instance variable to determine whether background task is active.
BOOL isBackgroundTaskRunning;
Then in runBackgroundTask
if (isBackgroundTaskRunning) {
// already running
return;
}
isBackgroundTaskRunning = TRUE;
...
isBackgroundTaskRunning = FALSE;
Here's what to do:
the background task saves its thread to a property somewhere using NSThread currentThread
the background task periodically checks the thread's isCancelled property.
the main thread sends cancel to the thread object saved by the background thread in step 1.
On exit, the background thread sets the property to nil.
All of the operations on the property used to store the thread in have to be protected by #synchronized or equivalent to prevent the main thread from sending cancel to a deallocated thread object.
The background thread can't do IO operations that block for more than a short period of time. In particular, synchronous downloading of URLs using NSURLConnection is out. If you are using NSURLConnection, you'll want to move to the asynchronous methods and a run loop (arguably, in that case, you can do away with the background thread altogether). If you are using POSIX level IO, use poll() with a timeout.
I don't think that it would be save to force the interruption of a method. What you can do is to change the state of your object and check that state inside your method implementation to early return in case of a cancel (but don't forget to release allocated objects).
This is how NSOperationQueue works. From the documentation:
Cancelling an operation does not immediately force it to stop what it is doing. Although respecting the value returned by the isCancelled is expected of all operations, your code must explicitly check the value returned by this method and abort as needed.
Run the method in a background thread, and keep a record of the NSThread. Then later, you can just end the thread.
Related
In the iPhone App am coding, I need to do several tasks in parallel :
PART 1 : All the time (even if the App is not active currently):
Fetch some data from a remote DB and persist it in local Sqlite
To do this, am firing a NSTimer in a separate queue in AppDelegate like this :
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
...
...
self.queueForDbFetch = dispatch_queue_create("queueForDbFetch", NULL);
self.queueForDbFetchTimer = dispatch_queue_create("queueForDbFetchTimer", NULL);
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(getDbData:) name:kNotif_GetDbData object:nil];
dispatch_async(self.queueForDbFetchTimer, ^(void) {
self.timerDbNotifier = [NSTimer scheduledTimerWithTimeInterval:60.0
target:self selector:#selector(scheduleNotificationToFetchDbData)
userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:self.timerDbNotifier forMode:NSDefaultRunLoopMode];
});
...
...
}
PART 2 :
And then, I need to asynchronously update the UI with the fetched data (which is from the local sqlite DB), which an doing with queues & timers (similar to the above) like this in a UIViewController class :
-(void) initializeThisView {
// Make sure the queues are created only once
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
self.queueForUiRefresh = dispatch_queue_create("queueForUiRefresh", NULL);
self.queueForUiRefreshTimer = dispatch_queue_create("queueForUiRefreshTimer", NULL);
});
[self scheduleUiDataRefresher];
}
-(void) scheduleUiDataRefresher {
dispatch_async(self.queueForUiRefreshTimer, ^(void) {
self.timerUiDataRefresh = [NSTimer scheduledTimerWithTimeInterval:60.0
target:self selector:#selector(loadUiData)
userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:self.timerUiDataRefresh forMode:NSDefaultRunLoopMode];
});
}
-(void) loadUiData {
dispatch_async(self.queueForUiRefresh, ^(void) {
[self refreshWithUiData:dict];
});
}
THE ISSUE :
The NSTimer instances (in both Part 1 and part 2) get fired once, and that's it. They don't repeat.
1. will creating NSTimer to repeat in the main queue block other user interaction with the App?
2. Is there any issue (or better way) in my structuring of the activities?
Don't create the timers in the dispatch_async() call. As soon as the block you pass to dispatch_async() has finished running (and it finishes directly after creating the timer), all data belonging to it is freed. I'm surprised it doesn't crash. Also, when you use scheduledTimerWithTimeInterval:target:selector:userInfo:repeats, the timer will already be scheduled to the main runloop. The call to NSRunLoop:addTimer: is not necessary, it will either have no effect or you will have a conflict in scheduling the timer.
To answer your questions:
Create the timers without dispatch_async(), just call NSTimer:scheduledTimerWithTimeInterval: directly. Do not use NSRunLoop:addTimer (unless you know exactly why you want it that way). Then in the selector that is being called by your timers, use dispatch_async() to fire off your asynchronous tasks.
However, if you are sure that these tasks do not take long, you might as well avoid using dispatch_async() altogether.
I'm kind of new to multithreading, and need some advice.
I'm using ARC in my code.
Problem : I've set up NSTimer in my app to fire every 1 second some method which creates and starts thread like this
//Create a new thread
mSomeThread = [[NSThread alloc] initWithTarget:self selector:#selector(someMethod) object:nil];
//start the thread
[mSomeThread start];
Where mSomeThread is an ivar
Let say the execution of mSomeThread takes more than 1 second, and the mSomeThread is allocated second time, i.e. according to ARC "rules" its released before be allocated one more time.
Does it mean that the first thread doesn't complete and and is forced to quite ?
An NSThread retains itself for the duration of its execution. There's no risk that resetting mSomeThread will cause a running thread to be terminated prematurely.
Yes. If you really need to keep reference to the current thread of execution for your someMethod then you need to wait for it to complete before you can actually start a new thread.
A quick way of doing this would be to add
while ([mSomeThread isExecuting]) {
sleep(1);
}
immediately after [mSomeThread start];.
By the way I'd rather re-implement NSThread and setup a repetitive NSTimer inside its main implementation.
Something like:
- main {
#autoreleasepool {
[NSTimer scheduledTimerWithTimeInterval:1 target:self selector:#selector(someMethod) userInfo:nil repeats:NO];
[[NSRunLoop currentRunLoop] run];
}
}
I need to make a call getValuesAndCalculate in my app, which should return only after doing its work. However, for doing its work, it needs to get records from a server, which has to be done through an async call. The server data is received through a callback function. Thus, in getValuesAndCalculate I need to wait till I have the data before proceeding with the calculations. How do I implement this?
Use protocols and delegates :
delegates are nothing but you assigning an object from your class to a object on the server side .
The server can use this object to call a method on your client side code.
Try using NSRunloop till you get the data from the server.
For eg :
while (!isFinished)
{
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:1.0]
}
You can implement Threads for this question i.e,
// in main thread
// start activity indicator
NSThread *calculateThread = [[NSThread alloc] initWithTarget:self selector:#selector(getValuesAndCalculate) object:nil];
[calculateThread start];
// End of Main thread
- (void)getValuesAndCalculate
{
// Perform transactions with server
[self performSelectorOnMainThread:#selector(continueMainThreadOperations) withObject:nil waitUntilDone:YES];
}
Thats it!
I have an app that needs to signal continuously a word in morse code. I did this by creating an NSThread and running some code inside the selector with a "while loop". Here is the code:
#implementation MorseCode
-(void)startContinuousMorseBroadcast:(NSString *)words{
if (!(threadIsOn)) {
threadIsOn = YES; s
myThread = [[NSThread alloc] initWithTarget:self selector:#selector(threadSelector:) object:words];
[myThread start];
}
if (morseIsOn) {
morseIsOn = NO;
}
else{
morseIsOn = YES;
}
}
-(void)threadSelector:(NSString *)words{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
while (![myThread isCancelled]) {
// ///it Does some code here
} //end While
NSLog(#"Cleaning the pool");
[pool drain];
}
#end
When exiting the application (the user presses the button), in the applicationDidEnterBackground the following selector is executed:
-(void)cleanUpMorseObject{ //this is defined in the MorseCode class, same as threadSelector
if (threadIsOn) {
NSLog(#"cleanUpMorseObject, threadIsOn");
threadIsOn = NO;
morseIsOn = NO;
[myThread cancel];
[myThread release];
}
}
The application responds correctly to the event, I’ve checked with nslog.
And then [MorseCode release] is called.
The code looks like this:
-(void)applicationDidEnterBackground{ //this happens in the ViewController
[theMorse cleanUpMorseObject]; //theMorse is an instance of MorseCode
[theMorse release];
}
The problem: Although I call [myThread release] and then [theMorse release] the retainCount of the theMorse is still above 0 (It doesn’t call the dealloc).
The Leaks Instrument doesn’t say I have a leak, but if I open and close the application for like 10 times eventually the Iphone resets. Also in the debugger eventually I see the “Received memory warning. Level=2”.
Also I never see the NSLog before the pool drain…
The app doesn't run in the background.
Any ideas? Thank you
You really should schedule the sending of the message on the RunLoop, the probably easiest way being to schedule a timer (repeat infinitely, and short repeat period like FLT_EPSILON or similar) instead of using threads for that.
Working with threads is complicated and as everyone should avoid it (as Apple stated in its Concurrency Programming Guide, and as most documentation said, "Threads are evil" ;)).
That's because multithreading is a vast and complicated subject, that needs synchronizations, resources protection, being aware of dead locks, critical sections & so on, good and adapted memory mgmt, and much much more. In general if you need to do stuff in the background:
Use mechanisms already in place (like asynchronous implementation of some operations and being signalled by delegate methods or notifications) if available
Use methods like performInBackground:
Use NSOperationQueues
Use GCD
And only in last resort and if there are no other options (or for really specific cases), use NSThread.
This will avoid you a lot of issues as all the other, higher APIs will take care of a lot of things for you.
Moreover, using threads for this task like you do is likely to use much more CPU (will probably reach 100% usage quickly) as there won't be any time left for the task scheduler (that also why even GCD that takes care of all stuff like that is way better than NSThreads, and scheduling the sending in the RunLoop is even better for the CPU if you don't need strong RT constraints)
First, retainCount can never return 0. It is a useless method. Don't call it.
Secondly, leaks only detects objects that are no longer referenced. If a thread is still running, it isn't leaked.
Finally, a thread doesn't stop when you call cancel. It just sets a flag that you have to check via isCancelled to see if it is time to stop work in the thread. Are you doing that?
OK -- easy stuff answered. Next? Try build and analyze. Then use the Allocations instrument and turn on reference count tracking. Then see what is calling retain an extra time.
I decided to give up the NSThread class and used another aproach:
-(void)playSOSMorse{
if ([myTimer isValid]) {
[myTimer invalidate];
[myTimer release];
myTimer = nil;
}
myTimer = [[NSTimer scheduledTimerWithTimeInterval:0.001
target:self
selector:#selector(tymerSelector)
userInfo:nil
repeats:NO] retain];
//the timer calls a selector that performs a selector in background
}
-(void)tymerSelector{
[self performSelectorInBackground:#selector(threadSelector2) withObject:nil];
}
-(void)threadSelector2 {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
//some code here
[pool drain];
//calls another selector on the main thread to see if it needs to fire the timer again and restart the cycle
[self performSelectorOnMainThread:#selector(selectorOnMainThread) withObject:nil waitUntilDone:NO];
}
-(void)selectorOnMainThread{
[myTimer invalidate];
[myTimer release];
myTimer = nil;
if (morseIsOn) { //this is a boolean that if it is true (YES) calls the timer again
[self playSOSMorse];
}
}
I hope this helps somebody :)
Thank you
I need to guarantee that the same thread performs various actions at arbitrary times. First the thread needs to initialize a library, then I want the thread to sleep until work needs to be done and upon user input, I need to be able to pass selectors or blocks for execution.
How can I setup an NSRunLoop to sleep after initialization? After which, how do I signal the run loop to wake up and do something?
I've tried reading the Threading Programming Guide for iOS, but I'd like to avoid setting up classes as custom input classes and use something more lightweight like performSelector:onThread:
Can I set a timer to fire forever from now so the run loop doesn't end?
Here's essentially what I want in pseudo-code:
// Initialization Code...
do {
sleepUntilSignaled();
doWorkSentToThisThread();
while (!done);
Where I send the work to do as a performSelector:onThread: message. It would be even better if I could send the run loop a block like: ^{[someObj message]; [otherObj otherMsg];} but I'd be happy with performSelector since I'm pretty sure that's possible without much extra coding.
Thanks!
You have all the necessary pieces together in your question. You start your thread and have it run it’s runloop. If you need the thread to do something you can use performSelector:onThread: on the main thread to do it.
There is one thing with the runloop you have to be aware though: It won’t run unless it has an input source or a timer attached to it. Just attach a timer to the run loop that fires some time in the distant future and you’re all set.
// Initialization code here
[NSTimer scheduledTimerWithTimeInterval: FLT_MAX
target: self selector: #selector(doNothing:)
userInfo: nil repeats:YES];
NSRunLoop *rl = [NSRunLoop currentRunLoop];
do {
[rl runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
} while (!done);
Using performSelector:onThread:withObject: you can also pass your block to the background thread. All you need to do is to write a method somewhere that takes an block as a parameter and runs it:
#interface NSThread (sendBlockToBackground)
- (void) performBlock: (void (^)())block;
#end
#implementation NSThread (sendBlockToBackground)
- (void) performBlock: (void (^)())block;
{
[self performSelector: #selector(runBlock:)
onThread: self withObject: block waitUntilDone: NO];
}
- (void) runBlock: (void (^)())block;
{
block();
}
#end
But maybe you should use a dispatch queue instead of all this. This requires less code and probably has less overhead also:
dispatch_queue_t myQueue = dispatch_queue_create( "net.example.product.queue", NULL );
dispatch_async( myQueue, ^{
// Initialization code here
} );
// Submit block:
dispatch_async( myQueue, ^{
[someObject someMethod: someParameter];
} );
A dispatch queue created using dispatch_queue_create is a serial queue - all blocks sent to it will be performed in the same order they arrived, one after another.
Consider using NSConditionLock. It is designed for tasks like this. Imagine that you have a queue with data. First thread adds data to queue, second thread waits for data and processes it.
id condLock = [[NSConditionLock alloc] initWithCondition:NO_DATA];
//First thread
while(true)
{
[condLock lock];
/* Add data to the queue. */
[condLock unlockWithCondition:HAS_DATA];
}
//Second thread
while (true)
{
[condLock lockWhenCondition:HAS_DATA];
/* Remove data from the queue. */
[condLock unlockWithCondition:(isEmpty ? NO_DATA : HAS_DATA)];
// Process the data locally.
}
I think you can use NSInvocationOperation with NSOperationQueue.