Bizarre Objective-C threading - ios

I've inherited a codebase for an iOS project and I wonder what the point of this code is:
-(void) someMethod {
FMDatabaseQueue *dbQueue = self.db;
// unimportant stuff
[Async series:#[
^(successBlock success, failureBlock failure) {
dispatch_async(dispatch_get_main_queue(), ^{
[dbQueue inDatabase:^(FMDatabase *db) {
// do database stuff
}];
});
},
^(successBlock success, failureBlock failure) {
dispatch_async(dispatch_get_main_queue(), ^{
[dbQueue inDatabase:^(FMDatabase *db) {
// do other database stuff
}];
});
}
];
}
Is there any reason to code something like this?
My reading is that the Async and the dispatch_async() back to the main thread makes the threading pointless.

The code is strange, but not because of this. The method +series probably does something in background (network, computation, $whatever) and then calls the series blocks. The execution of that blocks doesn't seem to be guaranteed on the main thread. But +series cannot know, whether they have to be executed on the main thread. (Maybe there is additional computation that should be done in background. Maybe the blocks are executed parallel.)
So, if there is something done, which has to be done on the main thread, you need another dispatch_async().
But yes: You get such constellations, when people try to do everything using blocks without thinking about the need. I do not know, why that happens, but using blocks many coders try to over-engineer their code.

Related

iOS ObjC: Why is dispatch_sync on mainThread not working while app is in background receiving an APNs fetch?

In my app I use the following method to check for values of certain variables which are meant to be accessed on the main thread only.
Now that I began to implement APNs and when my app is woken by APNs it seems that code execution (in background) is always stuck at the point indicated using comments:
- (void) xttSyncOnMainThread:(void (^)(void))prmBlock {
if (![NSThread isMainThread]) {
dispatch_queue_t mtQueue = dispatch_get_main_queue(); // will be executed
// execution is stuck here
dispatch_sync(mtQueue, prmBlock); // won't be executed
} else {
prmBlock();
}
}
Do I need to move all code to non-MT queues or am I missing something else?
Thanks a lot!
Because dispatch_sync on main queue cause deadlock.
More information about dispatch_sync and main queue is for example here:
dispatch_sync on main queue hangs in unit test
Why dispatch_sync( ) call on main queue is blocking the main queue?
Can you just use dispatch_async method ?
why are you passing prmBlock to dispatch_sync
usually it is like
dispatch_sync(dispatch_get_main_queue(), ^(void) {
// write the code that is to be executed on main thread
});
But if you use disptch_sync it will wait for the block to complete execution and then return. If you don't want to block the execution use
dispatch_async(dispatch_get_main_queue(), ^(void) {
// write the code that is to be executed on main thread
});
Ok, after some more testing I found that in my case (while the code in the question works just fine) the problem came from accidently calling the completionhandler from the APNs delegate too soon.
- (void) xttSyncOnMainThread:(void (^)(void))prmBlock {
dispatch_async(dispatch_get_main_queue(), ^{
//code here to perform
});
}

Issue in execute a method after completion of another method - iOS

I have two methods as loadTopicPostsFromDB and loadTopicPosts. In the loadTopicPostsFromDB method I am updating the value of a global NSString called strLastTimeStamp which should use in the loadTopicPosts. Thus, I want to execute loadTopicPostsFromDB first and after it finished(global string updated) I want to execute loadTopicPosts method.
This is how I did it. But, currently loadTopicPosts method executes before updating the global strLastTimeStamp, so always I get a wrong strLastTimeStamp.
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_group_t group = dispatch_group_create();
dispatch_group_async(group, queue, ^{
[self performSelectorOnMainThread:#selector(loadTopicPostsFromDB) withObject:nil waitUntilDone:NO];
});
dispatch_group_notify(group, queue, ^{
NSLog(#"LoadDBCompleted");
[self loadTopicPosts];
});
How can I do this, please advice me on what is the wrong in this implementation.
performSelectorOnMainThread: is finished as soon as iOS has put the task into a queue. The selector has most likely not even started running when the call returns. And really, you shouldn't be using performSelectorOnMainThread at all - the function isn't available in Swift, for good reason. The solution is a lot easier (fix the problems yourself):
dispatch_async (dispatch_get_main_queue (), ^{
[self loadTopicsFromDB];
[self loadTopicPosts];
});
You probably want to perform loadTopicsFromDB on a background thread though.
When you are doing something using network connection I advice you to use blocks to handle the endpoint of the call.
It is pretty simple to write in this code
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[self loadTopicsFromDB: ^(BOOL success, NSError *error) {
[self loadTopicPosts];
}];
});

dispatch_async(dispatch_get_main_queue() inside NSManagedObjectContext performBlock

What I want to do is create a async core data task on a background thread so as not to chew up the main thread, but I also want to do main thread work once the work is done...
Here's my task
-(void)doTaskwithCompletion:(coreDataCompletion)complete
{
[self.backgroundManagedObjectContext performBlock:^{
// do my BG core data task
[self saveContext:self.backgroundManagedObjectContext];
complete(YES);
}];
}
Here's my block method
[[MYCoreDataManager sharedInstance]doTaskwithCompletion:^(BOOL complete) {
if (complete == YES) {
dispatch_async(dispatch_get_main_queue(), ^{
// back to the main thread
});
}
}];
Something tells me this is wrong... but I can't find another way to put myself back on the main thread once the block has completed... notifications seem way too clunky.
I suppose in a nutshell my question is can I call dispatch_async(dispatch_get_main_queue() inside moc performBlock:^?
Essentially
-(void)doTaskwithCompletion:(coreDataCompletion)complete
{
[self.backgroundManagedObjectContext performBlock:^{
// do my BG core data task
[self saveContext:self.backgroundManagedObjectContext];
dispatch_async(dispatch_get_main_queue(), ^{
// back to the main thread
});
}];
}
I guess you know that it is a very common pattern to call something async and inside go back to mainQueue, i.e. for updating the UI:
dispatch_async(globalQueue, ^{
// do something
dispatch_async(mainQueue, ^{
// update UI
});
});
As you already named your variable self.backgroundManagedObjectContext you have probably heart of Multi-Context CoreData and I understand your concerns. As long as you are not trying to change something with this block for CoreData (on any Context) you are probably fine.
Just make sure that you use the correct initializer for your contexts, i.e. [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
"I suppose in a nutshell my question is can I call dispatch_async(dispatch_get_main_queue() inside moc performBlock:^?"
The answer is yes! In fact, you are doing the REVERSE of that when you call your performBlock from the main thread, right? This is a common feature of iOS. A cleaner way to do it perhaps is passing in a completion, and in that completion calling main...
right now, you have:
dispatch_async(dispatch_get_main_queue(), ^{
// back to the main thread
completion()
});
You could also write:
-(void)doTaskwithCompletion:(coreDataCompletion)complete
{
[self.backgroundManagedObjectContext performBlock:^{
// do my BG core data task
[self saveContext:self.backgroundManagedObjectContext];
complete()
}];
}
where complete has in it a call to the main thread.

Handle concurrency and asynchronous response

I am trying to implement concurrency in objective C. I have a problem with an actions that needs to be run in a synchronized way. The problem here is that I use function that executes a block after completion.
I want to connect to a bluetooth device to run some operations and connect to the next device.
for (Beacon * beacon in beacons) {
[beacon setDelegate:self];
[beacon connectToBeacon];
}
But the connection is asynchronous. The beacon call the delegate (in this case it's the same class) method didConnectSuccess when connection is successful.
I need to wait all my operations in "beaconDidConnect" and deconnection to finish before connecting to the next device.
I currently use a combination of dispatch queue and dispatch semaphore, my semaphore is an ivar
dispatch_queue_t myCustomQueue;
myCustomQueue = dispatch_queue_create("com.example.MyCustomQueue", NULL);
for (Beacon * beacon in beacons) {
[beacon setDelegate:self];
dispatch_async(myCustomQueue, ^{
dispatch_semaphore_wait(semaphoreBluetooth, DISPATCH_TIME_FOREVER);
[beacon connectToBeacon];
});
}
In combination with
- (void)beaconDidDisconnect:(Beacon *)beacon
{
dispatch_semaphore_signal(semaphoreBluetooth);
}
Without the dispatch_async, by blocking the callback (beaconDidConnect), the wait was causing a deadlock.
I wanted to dispatch_semaphore_wait in the for loop and not in the dispatch block but the wait causes the callback to wait again, causing a deadlock.
This way it seems to work but I found it a bit ugly.
My other issue is that in my beaconDidConnect method I need to chain asynchronous call and in each waiting the previous to terminate.
All those calls have a termination block, executing when the call is done. I could write instructions in deeper and deeper block but I'd like to avoid this.
I'd need an equivalent of the javascript "promise" concept.
Currently I have something with dispatch queue and dispatch semaphore but I sometimes have deadlock for unknown reason.
Eg :
- (void)beaconConnectionDidSucceeded:(Beacon *)beacon
{
dispatch_semaphore_t semaphoreEditing = dispatch_semaphore_create(1);
dispatch_queue_t editingQueue = dispatch_queue_create("com.example.MyCustomQueue.Editing", NULL);
// First writing procedure
dispatch_async(editingQueue, ^{
dispatch_semaphore_wait(semaphoreEditing, DISPATCH_TIME_FOREVER);
[beacon writeSomeCaracteristic:caracteristic withValue:value withCompletion:^(void) {
dispatch_semaphore_signal(semaphoreEditing);
}];
});
// A unknow number of writing sequences
dispatch_async(editingQueue, ^{
dispatch_semaphore_wait(semaphoreEditing, DISPATCH_TIME_FOREVER);
[beacon writeSomeCaracteristic:caracteristic withValue:value withCompletion:^(void) {
dispatch_semaphore_signal(semaphoreEditing);
}];
});
//
// ...
//
dispatch_async(editingQueue, ^{
dispatch_semaphore_wait(semaphoreEditing, DISPATCH_TIME_FOREVER);
[beacon writeSomeCaracteristic:caracteristic withValue:value withCompletion:^(void) {
dispatch_semaphore_signal(semaphoreEditing);
}];
});
// Terminate the edition
dispatch_async(editingQueue, ^{
dispatch_semaphore_wait(semaphoreEditing, DISPATCH_TIME_FOREVER);
[beacon disconnectBeacon];
dispatch_semaphore_signal(semaphoreEditing);
});
}
I want to write clear code that execute my instructions in a sequential way.
If your asynchronous methods do have a completion handler, you can "serialize" or "chain" a number of asynchronous calls like shown below:
[self asyncFooWithCompletion:^(id result){
if (result) {
[self asyncBarWithCompletion:^(id result){
if (result) {
[self asyncFoobarWithCompletion:^(id result){
if (result) {
...
}
}];
}
}];
}
}];
Of course, this gets increasingly confusing with the number of chained asynchronous calls, and especially when you want to handle errors, too.
With a third party library which especially helps to overcome these problems (including error handling, cancellation) it may look similar as the code below:
Given:
- (Promise*) asyncFoo;
- (Promise*) asyncBar;
- (Promise*) asyncFoobar;
"Chaining" the three asynchronous methods including error handling:
[self asyncFoo]
.then(^id(id result){
... // do something with result of asyncFoo
return [self asyncBar];
}, nil)
.then(^id (id result){
... // do something with result of asyncBar
return [self asyncFoobar];
}, nil)
.then(^id(id result) {
... // do something with result of asyncFoobar
return nil;
},
^id(NSError*error){
// "catch" any error from any async method above
NSLog(#"Error: %#", error);
return nil;
});
For general info about "Promises", please read wiki article Futures and Promises.
There are number of Objective-C libraries which implement a Promise.
Have you considered use NSOperation and NSOperationQueue?
If you need to wait for every beacon to run a set of operations before continue, you can store every set of operations in a NSOperation and put all the operations inside a NSOperationQueue with a maxConcurrentLimit of 1. It might be easier to cancel/pause/terminate every single operation and the queue will take care of the concurrency.
I kept the dispatch_queue and dispatch_semaphore for the connection but for the writing actions I use a library called Sequencer I found here.
It follows the Promises principle CouchDeveloper talked about.

How can I get back into my main processing thread?

I have an app that I'm accessing a remote website with NSURLConnection to run some code and then save out some XML files. I am then accessing those XML Files and parsing through them for information. The process works fine except that my User Interface isn't getting updated properly. I want to keep the user updated through my UILabel. I'm trying to update the text by using setBottomBarToUpdating:. It works the first time when I set it to "Processing Please Wait..."; however, in the connectionDidFinishLoading: it doesn't update. I'm thinking my NSURLConnection is running on a separate thread and my attempt with the dispatch_get_main_queue to update on the main thread isn't working. How can I alter my code to resolve this? Thanks! [If I need to include more information/code just let me know!]
myFile.m
NSLog(#"Refreshing...");
dispatch_sync( dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[self getResponse:#"http://mylocation/path/to/file.aspx"];
});
[self setBottomBarToUpdating:#"Processing Please Wait..."];
queue = dispatch_queue_create("updateQueue", DISPATCH_QUEUE_CONCURRENT);
connectionDidFinishLoading:
if ([response rangeOfString:#"Complete"].location == NSNotFound]) {
// failed
} else {
//success
dispatch_async(dispatch_get_main_queue(),^ {
[self setBottomBarToUpdating:#"Updating Contacts..."];
});
[self updateFromXMLFile:#"http://thislocation.com/path/to/file.xml"];
dispatch_async(dispatch_get_main_queue(),^ {
[self setBottomBarToUpdating:#"Updating Emails..."];
});
[self updateFromXMLFile:#"http://thislocation.com/path/to/file2.xml"];
}
In my connectionDidFinishLoading: I would try something like this:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0),^ {
if ([response rangeOfString:#"Complete"].location == NSNotFound]) {
// failed
} else {
//success
dispatch_async(dispatch_get_main_queue(),^ {
[self setBottomBarToUpdating:#"Updating Contacts..."];
});
[self updateFromXMLFile:#"http://thislocation.com/path/to/file.xml"];
dispatch_async(dispatch_get_main_queue(),^ {
[self setBottomBarToUpdating:#"Updating Emails..."];
});
[self updateFromXMLFile:#"http://thislocation.com/path/to/file2.xml"];
}
});
Then all that file access is happening in a background queue so the main queue is not locked up. The main queue will also complete this call to connectionDidFinishLoading much more quickly, since you're throwing all the hard work onto the default queue instead, which should leave it (and the main thread) ready to accept your enqueuing of the updates to the UI which will be done by the default queue as it processes the block you just enqueued to it.
The queue handover becomes
main thread callback to connectionDidFinishLoad:
rapid handoff to default global queue releasing main thread
eventual hand off to main queue for setBottomBarToUpdating: calls
performing main queue blocks on main thread to properly update UI
eventual completion of blocks on main queue
eventual completion of blocks on default queue
You've increased concurrency (good where you've good multi-core devices) and you've taken the burden of I/O off the main thread (never a good place for it) and instead got it focused on user interface work (the right place for it).
Ideally you woud run the NSURLConnection run loop off the main thread too, but this will might be enough for you to get going.
Which run loop are you running the NSURLConnection in? If it's the main loop, you're queueing up the setBottomBarToUpdating: calls behind the work you're already doing, hence the probable reason why you're not seeing the UI update.
You could also give performSelectorOnMainThread try like so:
if ([response rangeOfString:#"Complete"].location == NSNotFound]) {
// failed
} else {
//success
[self performSelectorOnMainThread:#selector(setBottomBarToUpdating) withObject:#"Updating Contacts..." waitUntilDone:false];
[self updateFromXMLFile:#"http://thislocation.com/path/to/file.xml"];
[self performSelectorOnMainThread:#selector(setBottomBarToUpdating) withObject:#"Updating Emails..." waitUntilDone:false];
[self updateFromXMLFile:#"http://thislocation.com/path/to/file2.xml"];
}

Resources