Earlier quoted context omitted.
He seems like a smart kid, but he's clearly not developed anything on iOS. One of the key things you learn as you're learning how to build an iOS app is that all UI code must be run on the main thread. It even says so right there in the [UIView class reference]( http://developer.apple.com/library/ios/#documentation/uikit/... ): > Threading Considerations Manipulations to your application’s user interface must occur o…
You're right in general but starting in iOS4: "Drawing to a graphics context in UIKit is now thread-safe." http://developer.apple.com/library/ios/#releasenotes/General... Some things won't work (notably UIWebView which also gets used in UITextView) but you actually can build a view in a NSOperation.
dvmLockMutex(&gDvm.heapWorkerLock);
//BUG: If a GC happens in here or in the new thread while we hold the lock,
// the GC will deadlock when trying to acquire heapWorkerLock.
if (!dvmCreateInternalThread(&gDvm.heapWorkerHandle, "HeapWorker", heapWorkerThreadStart, NULL))
{ dvmUnlockMutex(&gDvm.heapWorkerLock);
return false;
// Block until all pending heap worker work has finished.
void dvmWaitForHeapWorkerIdle() { int cc;
assert(gDvm.heapWorkerReady);
dvmChangeStatus(NULL, THREAD_VMWAIT);
dvmLockMutex(&gDvm.heapWorkerLock);
/* Wake up the heap worker and wait for it to finish. */
//TODO(http://b/issue?id=699704): This will deadlock if
// called from finalize(), enqueue(), or clear(). We
// need to detect when this is called from the HeapWorker
// context and just give up.
dvmSignalHeapWorker(false);
cc = pthread_cond_wait(&gDvm.heapWorkerIdleCond, &gDvm.heapWorkerLock);
assert(cc == 0);
dvmUnlockMutex(&gDvm.heapWorkerLock);
dvmChangeStatus(NULL, THREAD_RUNNING);