Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
- Subject: Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
- From: Jay Reynolds Freeman <email@hidden>
- Date: Tue, 13 Mar 2012 16:49:33 -0700
Notwithstanding the good advice about parallel programming given earlier in this thread, there are still possible problems. By way of illustration, a year or two ago I submitted a bug report (#8338166) about a problem of this sort in iOS. I will describe the problem here. (I am not looking for a workaround, I have one -- here I am just providing a real example from the past that may be of interest.)
Consider UIApplicationDelegate method "applicationWillTerminate:": Multithreaded applications may not be able to use it to shut down, because of the possibility of deadlock in communications between the main thread and other application threads.
Suppose we have a multithreaded iOS application whose non-main threads occasionally use "performSelectorOnMainThread:withObject:waitUntilDone:" to interact with the main thread. Now suppose the following things happen, in this order:
1) "applicationWillTerminate:" is called (by the OS, on the main thread).
2) Immediately thereafter, before "applicationWillTerminate" has completed, some other thread calls "performSelectorOnMainThread:withObject:waitUntilDone:", with "waitUntilDone:"'s value set to YES.
3) Suppose the application needs to get the other thread to do some shut-down work -- the kind of thing that is supposed to happen in "applicationWillTerminate:"
4) We now have a problem with deadlock. The application *cannot* communicate with the other thread from inside "applicationWillTerminate:", because the other thread is waiting for "performSelector ..." to run, and that won't happen until "applicationWillTerminate:" has itself returned. And if the application posts an event to the other thread and then returns from "applicationWillTerminate:", it is highly likely that the OS will terminate the application before the other thread has had a chance to act. So there is no reliable way to get the other thread to do its cleanup.
The point here is that since "applicationWillTerminate:" is called asynchronously from the point of view of the app, the app can *NEVER* communicate with any thread that may have to do clean-up work, by any communication protocol that requires the other thread to wait for the main thread to do something, for fear of a deadlock such as I have just described. That is a substantial restriction.
There are certainly other ways to do an iOS app shutdown, but this case illustrates the kind of deadlock that can happen if you do not think carefully about how things interact. The original intended use of "applicationWillTerminate:" is indeed a setup for deadlock to happen.
One should be on the lookout for similar situations with other iOS or MacOS methods.
-- Jay Reynolds Freeman
---------------------
email@hidden
http://web.mac.com/jay_reynolds_freeman (personal web site)
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden