How can one thread determine if another thread has failed?

Question

I have a background thread that does a ton of work - loading the application. The main thread shows the progress on the UIProgressView.

A background thread is created using performSelectorInBackground (although I disagree with this method if a different approach makes this easier)

[self performSelectorInBackground:@selector(loadAppInBackground) withObject:self]; 

In several cases, an error caused the background thread to fail (various errors during application development), which leads to a stop of the progress bar, but the user does not receive a clear indication that something is wrong.

I would like to discover this situation and fail more gracefully than just hang it until the user abandons the wait.

Since the duration of the download process can vary greatly, just timing is not an ideal option.

What is the best way for a foreground thread to detect that a background thread has failed? Since the foreground thread is busy working with the user interface, will a second background thread be required to monitor the first? It seems ugly.

Is there any mechanism for connecting threads to a thread that can be used to ping the background process? Better yet, a low-level system mechanism for checking the status of other threads?

The debugger knows about all the threads that work ... and seems to know their status. I am wondering if there is access to my application to do the same.

Answer 1

There appears to be no mechanism in object c for directly monitoring the state of the background thread. Any of the answers provided are worthy options ... either a timeout or the presence of a stream creates some evidence of its continued existence.

I was hoping for something simpler, more reliable and in real time.

I am going to experiment with catching an exception in a thread and possibly creating a notification like "BackgroundThreadException" that the foreground thread can listen to and respond to.

Answer 2

If the background task runs in some kind of regular loop (for example, there is a large loop in which most of the work is done), it can set the flag so often to indicate that it is still alive.

One way to do this is to have a background storage thread [NSDate timeIntervalSinceReferenceDate] somewhere, and in your main thread sometimes (maybe on a timer) compare this to the current time. If the difference is greater than some reasonable limit, you can guess that the background thread has died.

Another way is that the background thread just sets a boolean, and its main subject is polling and cleaning it up on a regular basis. If the logical value cannot be set again between polls of the main thread, you can conclude that it died.

The first method has the advantage that you can “set” a “reasonable limit” to carry code (in any thread) that is somewhat time-irregular. The second approach usually requires more predictable timings.

Of course, with any approach, you want to somehow avoid the “whistle” if the background thread has just finished, and you just haven't heard about it yet.

Answer 3

A common technique is to have an extra thread to check for signs of life in the flow in question — the so-called heartbeat flow. The thread of the flow of the heart checks the flow, checking whether it responds in a timely manner, if not, considers the flow dead and terminates it.

A simple implementation of a beat flow will check the counter, which is regularly incremented by another thread, if the counter does not increase for a certain time, it is considered dead, and then appropriate action can be taken, such as restarting the thread or killing. Another more common way is that the hb stream sends messages to the stream and checks for a timeout response.