How to use [performSelector: onThread: withObject: waitUntilDone:]? - objective-c

I tried to subclass NSThread in order to operate a thread with some data. I want to simulate the join() in python, according to the doc:
join(): Wait until the thread terminates. This blocks the calling thread until
the thread whose join() method is called terminates
So I think using performSelector: onThread: withObject: waitUntilDone:YES would be fine, but it does not work. It just do nothing and would not exit, running like forever.
This is my code:
#interface MyClass : NSThread
#property (strong, nonatomic) NSMutableArray *msgQueue;
#property (assign, nonatomic) BOOL stop;
#end
#implementation MyClass
-(id)init
{
self = [super init];
if (self) {
self.msgQueue = [NSMutableArray array];
self.stop = NO;
[self start];
return self;
}
return nil;
}
-(void)myRun
{
while (!self.stop) {
NSLock *arrayLock = [[NSLock alloc] init];
[arrayLock lock];
NSArray *message = [self.msgQueue firstObject];
[self.msgQueue removeObjectAtIndex:0];
[arrayLock unlock];
NSLog(#"%#", message);
if ([message[0] isEqualToString:#"terminate"]) {
self.stop = YES;
}
}
}
-(void)join
{
[self performSelector:#selector(myRun) onThread:self withObject:nil waitUntilDone:YES];
}
#end
int main(int argc, const char * argv[])
{
#autoreleasepool {
MyClass *a = [[MyClass alloc] init];
[a.msgQueue addObject:#[#"terminate",#"hello world"]];
//[a myRun]; // this line works so the myRun method should be good,
[a join]; // but I want this line work, and I have no idea what the problem is.
}
return 0;
}

From Apple's documentation on performSelector:onThread:withObject:waitUntilDone::
This method queues the message on the run loop of the target thread using the default run loop modes—that is, the modes associated with the NSRunLoopCommonModes constant. As part of its normal run loop processing, the target thread dequeues the message (assuming it is running in one of the default run loop modes) and invokes the desired method.
You probably never started a run loop on the thread, so it will never execute your myRun method, since it has no run loop to execute on.
As for Merlevede's answer, myRun is not enqueued on the same thread as join. join was called on your main thread, whereas you're trying to enqueue myRun on your secondary thread. So his theory is incorrect. Also from Apple's documentation regarding the wait parameter:
If the current thread and target thread are the same, and you specify YES for this parameter, the selector is performed immediately on the current thread. If you specify NO, this method queues the message on the thread’s run loop and returns, just like it does for other threads. The current thread must then dequeue and process the message when it has an opportunity to do so.
So even if it was on the same thread, it wouldn't be stuck waiting, it would just execute it right away as if you had directly called the method instead of using performSelector: in the first place.

You're basically in a deadlock condition.
-(void)join
{
[self performSelector:#selector(myRun) onThread:self withObject:nil waitUntilDone:YES];
}
join is waiting for myRun to finish (waitUntilDone flag), but myRun is enqueued on the same thread as join, so it's also waiting for join to finish.
For performSelector:onThread:withObject:waitUntilDone: you would never pass the current thread as the thread parameter.

Related

Clarifications needed for a crash using NSArray, blocks and Manual Reference Counting

I need some clarifications on a crash I'm encountering using NSArray, blocks and Manual Reference Counting. My goal is to store blocks on a collection (NSArray in this case) in order to reuse them in the future.
I've setup a small sample to replicate the issue. In particular, I have a class Item that looks like the following:
#import <Foundation/Foundation.h>
typedef void(^MyBlock)();
#interface Item : NSObject
- (instancetype)initWithBlocks:(NSArray*)blocks;
#end
#import "Item.h"
#interface Item ()
#property (nonatomic, strong) NSArray *blocks;
#end
#implementation Item
- (instancetype)initWithBlocks:(NSArray*)blocks
{
self = [super init];
if (self) {
NSMutableArray *temp = [NSMutableArray array];
for (MyBlock block in blocks) {
[temp addObject:[[block copy] autorelease]];
}
_blocks = [temp copy];
}
return self;
}
The usage is described below (I'm using in the app delegate).
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
__block typeof(self) weakSelf = self;
MyBlock myBlock1 = ^() {
[weakSelf doSomething1];
};
MyBlock myBlock2 = ^() {
[weakSelf doSomething1];
};
NSArray *blocks = #[myBlock1, myBlock2];
// As MartinR suggested the code crashes even
// if the following line is commented
Item *item = [[Item alloc] initWithBlocks:blocks];
}
If I run the app, it crashes with an EXC_BAD_INSTRUCTION (note that I've already enabled All Exceptions breakpoints). In particular, the app stops in the main.
int main(int argc, const char * argv[]) {
return NSApplicationMain(argc, argv);
}
Note: As suggested by Ken Thomases, if you use bt command on llvm console, you are to see the back trace. In this case it shows the following:
-[__NSArrayI dealloc]
If I comment the [weakSelf doSomethingX]; it works without crashes (it does not mean that is correct).
Modifying the code a little bit like the following, all runs ok.
// Item does not do anymore the copy/autorelease dance
// since used in the declaration of the blocks
- (instancetype)initWithBlocks:(NSArray*)blocks
{
self = [super init];
if (self) {
_blocks = [blocks retain];
}
return self;
}
and
__block typeof(self) weakSelf = self;
MyBlock myBlock1 = [[^() {
[weakSelf doSomething1];
} copy] autorelease];
MyBlock myBlock2 = [[^() {
[weakSelf doSomething1];
} copy] autorelease];
NSArray *blocks = #[myBlock1, myBlock2];
Item *item = [[Item alloc] initWithBlocks:blocks];
What is the point here? I think I'm missing something but I don't know what.
Update 1
Ok. I'll try to recap my thoughts based on the comments with #Martin R and #Ken Thomases.
A block, by default, is created on stack if a copy message is not sent to it (ARC does this for us) in order to move it on the heap. So, the situation in this case is the following. I create an autorelease array and I add two blocks where retain is called in a implicit manner. When the applicationDidFinishLaunching method finishes is execution, the blocks, since created on the stack (they are automatic variables) disappear. In a later moment, the array called blocks will be released since has been marked as autorelease. So, it will crash since it will send a release object to blocks that do not exist anymore.
So, my question is the following: What does it mean to send a retain message to a block that is on the stack? Why the array is the source of the crash (see the back trace)? In other words, since a block is on the stack, will it bump the retain count of it? And when it goes out of scope? In addiction, why if I comment the [weakSelf doSomething1] line the code works without problems? Not very clear to me this part.
You are sticking an object from the stack into an autoreleased array. BOOM ensues.
Consider:
typedef void(^MyBlock)();
int main(int argc, char *argv[]) {
#autoreleasepool {
NSObject *o = [NSObject new];
MyBlock myBlock1 = ^() {
[o doSomething1];
};
NSLog(#"o %p", o);
NSLog(#"b %p", myBlock1);
NSLog(#"b retain %p", [myBlock1 retain]);
NSLog(#"b copy %p", [myBlock1 copy]);
NSLog(#"s %p", ^{});
sleep(1000000);
}
}
Compiled/run as -i386 (because the #s are smaller and more obvious):
a.out[11729:555819] o 0x7b6510f0
a.out[11729:555819] b 0xbff2dc30
a.out[11729:555819] b retain 0xbff2dc30
a.out[11729:555819] b copy 0x7b6511a0
a.out[11748:572916] s 0x67048
Since the object is at 0x7b, we can assume that is the heap. 0xb is really high memory and, thus, the stack.
The retain doesn't cause a copy (because doing so would have invariably led to leaks) and retain on a stack based object is meaningless.
If you change the [o doSomething1]; to [nil doSomething1]; then that becomes a static block and that lives in readonly mapped memory (readonly-executable pages from the mach-o's TEXT segment) and, thus, there is no allocation to deallocate and retain/release/autorelease are no-ops.
As you can see, the static block ended up around 0x67048 (this number may change from run to run, btw, for a variety of reasons. Low in memory.
In fact, because of the sleep(), we can run vmmap against the a.out process and see:
==== Writable regions for process 11772
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
__DATA 00067000-00068000 [ 4K] rw-/rwx SM=ZER /tmp/a.out
That is, the static block was in the first 4K segment of mapped writable regions from the mach-o file. Note that this doesn't mean the code is in that writable region (SECURITY HOLE if it were). The code is in the TEXT segment mapped into the readable regions.

Objective-C : Synchronizing code

I have a simple class with two ivars, a NSMutableArray and a BOOL. Objects of this class are able to shuffle elements in the array when they are sent the startShuffling message. They do so until they receive the stopShuffling message.
To make it work, the startShuffling method set the boolean to YES, and then dispatch the block of code that shuffles (while(self.isShuffling) { //... } on a concurrent queue. The stopShuffling set the boolean to NO, so that the shuffling process will terminate on the next loop turn.
Here is the interface :
#interface MyClass : NSObject <NSCoding> {
#private
NSMutableArray *elements_;
__block BOOL isShuffling_;
}
#property(readonly) BOOL isShuffling;
-(void)startShuffling;
-(void)stopShuffling;
#end
And the implementation :
#implementation MyClass
#synthesize isShuffling = isShuffling_;
-(void)startShuffling {
if(self.isShuffling) {
return;
}
isShuffling_ = YES;
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(queue, ^{
while(isShuffling_) {
// code that shuffles, one element by turn
NSUInteger elementIndex = arc4random() % [elements_ count];
id c = [[elements_ objectAtIndex:elementIndex] retain];
[elements_ removeObjectAtIndex:elementIndex];
[elements_ insertObject:c atIndex:[elements_ count]];
[c release];
}
});
}
-(void)stopShuffling {
isShuffling_ = NO;
}
#end
My class conforms to NSCoding protocol and I don't want to abort encoding even if the object is shuffling. Instead I want my object to stop shuffling and then encode itself. So I have written this encoding method :
-(void)encodeWithCoder:(NSCoder *)aCoder {
if(self.isShuffling) {
[self stopShuffling];
}
[aCoder encodeObject:elements_ forKey:kIVPCodingKeyMyClassElements];
}
Finally, here my question.
I think it is possible for the encodeObject:forKey: method to get called while the shuffling loop terminates its last turn (maybe I'm wrong ?).
Is there any way I can make encodeObject:forKey: method get called after wait for the shuffling loop last turn to terminate ?
Yes, the the shuffle code may still be running when the encodeObject:forKey: method is called.
In general, you don't want to dispatch some random block off onto a queue that executes for a really long time, potentially forever. You want to break up the work into blocks of work. And there-in lies your answer.
Something like:
- (void)shuffleAndCheck
{
if (stillShuffling) {
dispatch_async(globalConcurrentQueue, ^{
dispatch_apply(shuffleQueue, ^{... shuffle one card code ...});
});
dispatch_async(shuffleQueue, ^{ [self shuffleAndCheck]; });
}
}
- (void) startShuffling
{
if (stillShuffling) return;
stillShuffling = YES;
[self shuffleAndCheck];
}
- (void) stopShuffling
{
stillShuffling = NO;
dispatch_async(shuffleQueue, ^{ ... encode stuff here ... });
}
Or something.

Objective-c Async memory management

I've had a look around but have been unable to find a definitive answer to this question.
If I have a class that performs an async operation, when and how do I release it?
-(void)main
{
AsyncObject *async = [[AsyncObject alloc] initWithDelegate:self];
[async goDoSomething];
}
-(void)didSomething:(Result*)result
{
}
When do I release *async?
You could keep a private property to save the value, or, if you have control over the AsyncObject, pass the instance in the didSomething: selector.
I think the first option is better since you know the object will be retained until you get your delegate call.
Option 1:
ClassName.m
#interface ClassName ()
#property (nonatomic, retain) AsyncObject* async;
#end
#interface
//...
-(void)main
{
async = [[AsyncObject alloc] initWithDelegate:self];
[async goDoSomething];
}
-(void)didSomething:(Result*)result
{
[async release];
async = nil;
}
Option 2:
-(void)aysncObject:(AsyncObject*)async didSomething:(Result*)result {
[async release];
}
If your object runs its asynchronous task on a background thread, or is the target of a timer, or uses GCD and is referenced within the scope of the dispatched block (the ^ {} kerjigger) then it will be retained for you for the lifetime of that background operation.
So the normal use case would be:
AsyncObject *async = [[AsyncObject alloc] initWithDelegate:self];
[async goDoSomething];
[async release];
Now, it's possible to work in the background with an object that is not retained (e.g. by using a __block-scoped reference to the object with GCD, or by detaching your worker thread with pthreads instead of NSThread/NSOperation) but there are no typical use cases I can think of offhand where that would happen. In such a case, you should ensure that -goDoSomething internally retains and releases self for the duration of the operation.
(If somebody can think of a case where the object is not retained for you, please post in the comments and I'll update my answer.)
Thanks for the help guys, I did a bit of experimenting with NSURLConnection to see how it handled it (As you autorelease that and it will continue on with it's async operations).
Turns out at the beginning of every async step it internally bumps its retain count and at the end of every async step it internally releases itself.
This means that it can be sent autorelease/release and it won't actually be release until it has completed it's current operation.
// MAIN.M
-(void)main
{
AsyncObject *async = [[[AsyncObject alloc] initWithDelegate:self] autorelease];
[async goDoSomething];
}
-(void)didSomething:(Result*)result
{
}
// ASYNCOBJECT.M
-(void) goDoSomething
{
[self retain];
}
-(void) finishedDoingSomething
{
[delegate didSomething:result];
[self release]
}

When is an autoreleased object actually released?

I am new in objective-c and I am trying to understand memory management to get it right.
After reading the excellent
Memory Management Programming Guide for Cocoa by apple my only concern is when
actually an autoreleased object is released in an iphone/ipod application. My understanding is at the end of a run loop. But what defines a run loop in the application?
So I was wondering whether the following piece of code is right. Assume an object
#implementation Test
- (NSString *) functionA {
NSString *stringA;
stringA = [[[NSString alloc] initWithString:#"Hello"] autorelease]
return stringA;
}
- (NSString *) functionB {
NSString *stringB;
stringB = [self functionA];
return stringB;
}
- (NSString *) functionC {
NSString *stringC;
stringC = [self functionB];
return stringC;
}
- (void)viewDidLoad {
[super viewDidLoad];
NSString* p = [self functionC];
NSLog(#"string is %#",p);
}
#end
Is this code valid?
From the apple text I understand that the NSString returned from functionA is valid in the scope of functionB. I am not sure whether it is valid in functionC and in viewDidLoad.
Thanks!
Yes, your functions are valid, and return objects using correct Cocoa conventions for retain/release/autorelease/copy.
To answer your question about what the runloop is, in your application's main() function, it invokes UIApplicationMain(). You can imagine UIApplicationMain looks something like this:
void int UIApplicationMain (int argc, char *argv[], NSString *principalClassName, NSString *delegateClassName) {
UIApplication *app = /* create app using principalClassName */;
[app setDelegate:/* create delegate using delegateClassName */];
while (![app shouldTerminate]) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
event = [app getNextEvent];
[app dispatchEvent:event];
[pool drain];
}
}
That while loops is similar to what the UIKit is actually doing, and each trip through that while loop is like a trip through the runloop, where the function getNextEvent blocks waiting for some event to happen. All of your methods are typically called from within something like dispatchEvent:. You might try setting a break point in one of your methods, like an IBAction, and looking in the debugger call stack way up at the top to see the names of the UIKit methods that handle the events and runloop. Since each of your methods are called from within that while loop, each time you call autorelease on an object, that object is added to that outter pool in the run loop. When the current event is finished being dispatched, the pool is drained, and those objects are finally sent release messages.
One last note. There can be more than one autorelease pool, that aren't always at the end of the event loop. Sometimes you might allocate tens of thousands of objects in one trip thorough the event loop. When that happens, you might setup additional inner auto release pools in your own methods to keep the number of autoreleased objects in autorelease pools down. Auto release pools can stack.
There's nothing wrong with that code. It will compile and run as you expect.
The NSString object returned from functionA is still valid upon return since it's being passed down the stack to the next guy (functionB) who is now keeping track of it.

NSThread object retained twice?

I have a class derived from NSThread:
#interface FSEventMonitorThread : NSThread {
FSEventStreamRef m_fseStreamRef;
CFRunLoopRef m_runLoop;
}
- (id) initWithStream:
(FSEventStreamRef)fseStreamRef;
- (void) dealloc;
- (void) main;
#end
#implementation FSEventMonitorThread
- (id) initWithStream:
(FSEventStreamRef)fseStreamRef
{
if ( self = [super init] )
m_fseStreamRef = fseStreamRef;
return self;
}
- (void) dealloc
{
CFRunLoopStop( m_runLoop );
FSEventStreamStop( m_fseStreamRef );
[super dealloc];
}
- (void) main
{
m_runLoop = CFRunLoopGetCurrent();
FSEventStreamScheduleWithRunLoop(
m_fseStreamRef, m_runLoop, kCFRunLoopDefaultMode
);
FSEventStreamStart( m_fseStreamRef );
CFRunLoopRun();
}
#end
Elsewhere (inside a C++ function), I create an instance:
m_thread = [[FSEventMonitorThread alloc] initWithStream:m_fseStreamRef];
My understanding is that the retain-count should now be 1.
In another C++ function, I want to stop and deallocate the thread:
[m_thread release];
Yet the dealloc method is not called. If I instead do:
[m_thread release];
[m_thread release];
then dealloc is called which implies the retain-count was 2. But how did it get to be 2?
Note that the documentation for NSThread only mentions retaining when using detachNewThreadSelector:toTarget:withObject:.
The framework itself keeps ownership of the thread. This is necessary so that the thread object doesn't go away while the main method is executing. If you want to stop a thread, you are doing it the wrong way. You must provide some sort of inter-thread communication to signal the thread's main method that it should stop whatever it is doing, clean up, and exit. Once that happens, relinquishing your ownership of the thread will cause the thread to dealloc. You should never simply over-release something to get it to "go away". If you are doing that, you are almost certainly not using the provided objects the way they are meant to be used, as in this case.
A very simple example to cancel your thread might be:
- (void)finishThread
{
if( [NSThread currentThread] != self ) // dispatch this message to ourself
[self performSelector:#selector(finishThread) onThread:self withObject:nil waitUntilDone:NO];
else
CFRunLoopStop(CFRunLoopGetCurrent());
}