site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Dec 15, 2006, at 8:24 PM, Terry Lambert wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com Let me say up front that I don't believe this is a kernel problem, and the "showallstacks" command should confirm that there are still stacks running in the process. You may end up (if it has already been taken off the active process list) having to track down the task from the zombie list, if it doesn't show up in the task list - meaning it won't show in the "showallstacks". -- Terry Perhaps I don't understand at Apple's implementation layer what happens to a thread during a pthread_join(). My understanding of pthread_join() is that the calling thread blocks until the referenced thread terminates either explicitly by a call to pthread_exit(), implicitly by returning from the thread's main routine, or by terminating at a cancellation point after having been cancelled, that pthread_join() is analogous to waitpid() (without the WNOHANG option). So, a stack continues to exist even after it has been joined? Are stacks then cleaned up asynchronously? Or is there a subsequent *_np API I need to call to get stacks to get cleaned up? Every thread that I created I successfully joined without exception since I logged the thread IDs and accounted for them all. I'll see what I can do about the kernel debugging. Assuming there is yet another thread hanging around, I have no idea what I would be changing in my code beyond what I'm doing now. Using "top", the number of threads ("#TH") in the running program is exactly equal to the number I'm creating plus the main thread, so I have no idea what other threads could be hiding. smime.p7s