views:

123

answers:

2

I'm currently working on an iPhone app and I have a library from a third-party that has asynchronous behavior but that I'd like to wrap with my own class and make it appear synchronous.

The central class in this library, let's call it the Connection class, has several functions that have their ultimate result resolved when methods on an instance of a delegate class are called. What I'm trying to do is wrap this class and delegate so that it appears to be synchronous instead of asynchronous. If I were doing this in Java I would use FutureTask or a CountdownLatch or just join(). But I'm not sure the best way to do this in Objective C.

I started by creating a NSThread extenstion, NFCThread, which conforms to the above mentioned delegate protocol. The idea is that I would init and NFCThread, pass the NFCThread instance to Connection's setDelegate method, start the thread and then call an asynchronous method on Connection. My expectation is that one of the three delegate methods on the NFCThread instance would be called ultimately causing the thread to exit.

To simulate a join I did the following. I added a NSConditionalLock to NFCThread:

joinLock = [[NSConditionLock alloc] initWithCondition:NO];

The code around the call to Connection looks something like this:

NFCThread *t = [[NFCThread alloc] init];
[connection setDelegate:t];
[t start];

[connection openSession];
// Process errors, etc...

[t.joinLock lockWhenCondition:YES];
[t.joinLock unlock];
[t release];
[connection setDelegate:nil];

The protocol for the delegate has three methods. In NFCThread I implemented each method something like this:

- (void)didReceiveMessage:(CommandType)cmdType 
                     data:(NSString *)responseData 
               length:(NSInteger)length {
    NSLog(@"didReceiveMessage");
    // Do something with data and cmdType...
    [joinLock lock];
    [joinLock unlockWithCondition:YES];
    callBackInvoked = YES;
}

I overloaded NFCThread's main method so that it just loops continually. Something like this:

while (!callBackInvoked) { ; }

I found that this isn't really a good idea since it cause cpu usage to go through the roof. So instead I tried using a run loop from some examples I found on this site:

NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
[runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];

while (!callBackInvoked) {
    [runLoop runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
}

In both of my implementations the main thread is always blocked and it appears that none of the delegate methods are ever called. However, I know that the library is functioning properly and that calls to the delegate methods are normally called.

I feel like I'm missing something obvious here. Any help much appreciated.

Rich

A: 

You want a semaphore, which will allow your primary codepath to block until your asynchronous callback signals the semaphore and allows it to continue.

Semaphores are available in iOS 4 through Grand Central Dispatch.

It appears that the behavior of semaphores can be implemented in iOS 3 with NSCondition.

Seamus Campbell
Thanks Seamus, but unfortunately the library that I mention in this question is compiled to 3.x so, afaik, we can't use GCD. Any other suggestions?
richever
A: 

Ok, so there are a few different issues here, I'm trying to think where to start.

But just so we understand what you're trying to accomplish, when you say you want the call to "appear" synchronous, do you mean you want the call to block? Are you making this call from the main thread? If so, then it seems you are blocking the main thread by design.

Keep in mind the third party library is probably scheduling events on the main run loop. You can create your own run loop and run it in another thread, but have you told the other library to use that run loop for its events? (For example, it could be making async network requests that are scheduled on the main run loop which you have blocked)

I would rethink what you're doing a bit, but first we would need to know if your intention is to block the thread from which you are making this call. Also, do you need to support iPhoneOS 3.x?

Firoze Lafeer
Thanks, Firoze. Yes, our intention is to have our synchronous call to block. This third party library is actually interfacing with an SD card, but I think that's just a detail. Also, upon closer inspection, I just determined that calls to the delegate methods also happen on the main thread. Might this render this whole discussion moot?
richever
Well, I'm not sure it's moot. The thing is if you want the call to block, and you block the main thread, then this other library cannot finish its work. So one answer would be to make the synchronous call from a different thread, which would block *that* thread, but still allow the main thread to continue to function normally.Of course if you end up creating and blocking many threads this way, that's not very good. In any case, I would think about *why* you want this sync and maybe think of a non-blocking way to do the same thing (requires knowing more of what you are trying to do here)
Firoze Lafeer
I'm calling the blocking method in a different thread now, as you suggested Firoze, and this seems to work. Sort of. See my follow on question: http://stackoverflow.com/questions/3444557/error-at-nsrunloop-after-returning-from-thread-method-with-nsautoreleasepool
richever