So, the problem actually begins _before_ you create the second thread. If you
look at all of the running threads, you’ll see the first thread you created
(“Thread 6” on my simulator) locked up inside its dealloc method:
(lldb) bt
* thread #6: tid = 0x7b7198, 0x0000000104b4ed92
libsystem_kernel.dylib`syscall_thread_switch + 10
frame #0: 0x0000000104b4ed92 libsystem_kernel.dylib`syscall_thread_switch +
10
frame #1: 0x0000000104b2ddaf libsystem_platform.dylib`_OSSpinLockLockSlow +
65
frame #2: 0x00000001016dba56 Foundation`_NSThreadGet0 + 87
frame #3: 0x00000001017d794d Foundation`-[NSThread cancel] + 29
* frame #4: 0x000000010164d83b ThreadFail`-[MyThread
dealloc](self=0x00007fdcb8d328b0, _cmd="dealloc") + 43 at MyThread.m:15
frame #5: 0x0000000101b62afe
libobjc.A.dylib`objc_object::sidetable_release(bool) + 232
Calling [self cancel] inside an NSThread’s dealloc method is a bad idea —
first, it’s not necessary (if the thread’s being dealloced, it can’t be running
anymore), and second, you’re trying to get the thread to do stuff while it’s in
the middle of being torn down. That’s probably what’s causing the deadlock.
And since the lock that’s stuck looks like a shared one used by all NSThreads,
you then get a “tar baby” effect where other NSThread operations also lock up
as soon as they try to acquire that lock.
—Jens
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
