Weakify | way use a method on a class as a closure value | Wrapper library

The NSThread cancel method does not perform preemptive cancelation. All it does is set a Boolean that you can check in your other thread. As the docs say:

The semantics of this method are the same as those used for Operation. This method sets state information in the receiver that is then reflected by the isCancelled property. Threads that support cancellation should periodically call the isCancelled method to determine if the thread has in fact been cancelled, and exit if it has been.

For more information about cancellation and operation objects, see Operation.

Whether canceling NSThread, dispatch work item, or operations, the only time you can cancel something that is currently running on another thread is if that code on that thread was explicitly written to support cancelation (e.g., in compute tasks, periodically checking isCancelled state).

In short, your issue will not be solved by the use of cancel method.

If I understand you correctly, you are saying that something is holding on to self for 30+ seconds when called from a background thread, but not when you call it from the main thread. That is a pretty unusual scenario.

It’s hard to say what would cause that on the basis of what has been provided. (It would be nice if you could prepare a MCVE that manifests this problem without all of these external dependencies.)

Anyway, I would suggest a few things:

1. Add log statements before, in, and after your solutionFallback. Confirm whether this method is taking longer. This helps you narrow down the source of the delay. If those methods are taking longer, then that’s clearly the problem and you can set yourself on diagnosing why they’re taking longer than you expected. If they’re returning immediately, then we know the problem rests elsewhere.

2. I would suggest turning on the main thread checker, if you have not already. Historically attempting UI updates on a background thread would cause mysterious delays, and the main thread checker identifies these issues immediately.

   I don’t think it will find anything causal, but you might also temporarily turn on the thread sanitizer, too, and make sure you do not see any issues there.

   The Main Thread Checker and TSAN are discussed in Diagnosing Memory, Thread, and Crash Issues Early.

3. If you are not seeing the object deallocated in a timely manner, press the “Debug Memory Graph” button during this 30+ second delay. (See Gathering Information About Memory Use or WWDC video Visual Debugging with Xcode.) This will show you precisely what is keeping the lingering strong reference. And if you turn on the “Malloc stack” feature (described in How to debug memory leaks when Leaks instrument does not show them? or in that video), it will show you not only what has the strong reference, but where the strong reference was originally established. It obviously cannot tell you why or where the strong reference wasn’t removed, but at least it will provide a list of strong references from which you can commence your analysis.

I agree with the comments that you have some structural difficulties with your code.

But there are still times in which I need code to run on the main thread and I don't know if I'm already on the main thread or not. This has occurred often enough that I wrote a ExecuteOnMain() function just for this: