performSelector:withObject: and its retain behavior

Question

This is an already answer question within SO but I cannot find it in the Apple documentation anywhere. Could you point me in the right direction?

Within the following topics

Do I have to retain an object before passing it to -performSelector:withObject:afterDelay:?

the effect on retain count of performSelector:withObject:afterDelay:inModes

Is object that calls performSelector:withObject:afterDelay get retained by the NSRunLoop?

the default behaviour seems to be the following: it retains the receiver and the argument(s).

I'm using the following code

[[self delegate] performSelector:@selector(tryToSendStoreData:) withObject:userData];

where userData is an autoreleased oject.

Logging the retain count (I know that it could be not valid to do it) the data passed in increments its retain count. When the method is invoked on the delegate, the retain count is not equal to one.

So, my question is: do I need to perform some memory management to avoid leaks or do I have to trust on Apple stuff? Here I'm speaking as an agnostic since I cannot find the right docs.

Thank you in advance.

Answer 1

You are looking at the wrong function in the documentation.

Retain

performSelector:withObject:afterDelay: and similar functions (with afterDelay) retain the receiver and arguments, because the execute later

No Retain

performSelector:withObject: and similar functions (without afterDelay) do not retain anything, since they just call the function directly.

[[self delegate] performSelector:@selector(tryToSendStoreData:) withObject:userData];

does the exact same thing as

[[self delegate] tryToSendStoreData:userData];

Answer 2

While @newacct gave the correct answer, but it was not for the question that @Flex_Addicted had asked, i.e. citations from Apple's documentation that the observed behaviour is indeed guranteed. Below is a (partial) citation, but we'll have to go through a couple of hoops to get there -

The documentation for performSelector:withObject:afterDelay: states that

This method sets up a timer to perform the aSelector message on the current thread’s run loop.

so next we head over to the documentation for NSRunLoop and there we find that only one method exists that allows the capability to enqueue stuff on the run loop -
performSelector:target:argument:order:modes:, whose documentation states that

This method sets up a timer to perform the aSelector message on the current thread’s run loop at the start of the next run loop iteration. The timer is configured to run in the modes specified by the modes parameter...The receiver retains the target and anArgument objects until the timer for the selector fires, and then releases them as part of its cleanup.

Of course, nothing guarantees that [NSObject performSelector:withObject:afterDelay:] always uses [NSRunLoop performSelector:target:argument:order:modes:] (although this answer would be complete if someone could come up with documentation for that), but at least this is a step towards the mystery of answering the riddles the holy scriptures riddle us with.