Re: NSThread subclass get blocked on 'start' method call
Re: NSThread subclass get blocked on 'start' method call
- Subject: Re: NSThread subclass get blocked on 'start' method call
- From: Jens Alfke <email@hidden>
- Date: Mon, 28 Sep 2015 13:28:25 -0700
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 (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