site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Resent-date: Sun, 12 Sep 2004 15:17:04 -0400 Resent-from: Marc Van Olmen <marc@sky4studios.be> Resent-message-id: <A6EE50FC-0418-11D9-BE45-00306570AF76@sky4studios.be> Resent-to: darwin-dev@lists.apple.com HI, thanks for you time again, mvo ps: so my function looks like this (with the 2 options): void* cOS_Thread::Entry(cOS_Thread* inCAPThread) { int anError; On Sep 11, 2004, at 12:16 PM, Marc Van Olmen wrote: Hi Paul Thanks for you reaction: You are leaking threads. You need to either detach or join them. If you are comparing how the two options perform, it may be better to not use the semaphore at all in the attached case and simply join the thread. I will keep you up to date on my progress, mvo However, if at some point you run into a case where you have an attached thread which you know for certain has finished executing and are finished tracking it, I think the most efficient thing to do to release the resource at this point is to detach it. There's no reason you can't detach an attached thread that has finished executing. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... I can confirm that when I call pthread_detach at the end of the function entry there is no leak any more in the virtual memory space. I'm still surprised that I need to call pthread_detach myself at the end of function call, because couldn't find any remark of that in the book, and threads under OS X seems to be created by default in 'attach' mode. one remark: The detach-thread version with semaphore techniques uses less memory then the 'attach'-thread and pthread_join technique. void* theAnswer = NULL; if(inCAPThread->mThreadRoutine != NULL) { #if FW_SEMAPHORE_WAIT_TECHNIQUE inCAPThread->mWaitSemaphore->Lock(); #endif theAnswer = inCAPThread->mThreadRoutine(inCAPThread->mThreadParameter); #if FW_SEMAPHORE_WAIT_TECHNIQUE inCAPThread->mThreadFinished = true; inCAPThread->mWaitSemaphore->Notify(); inCAPThread->mWaitSemaphore->Unlock(); #else anError = pthread_detach(inCAPThread->mPThread); OS_ThrowIf(anError != 0, anError, "cOS_Thread::Entry: Could not detach the thread"); #endif } inCAPThread->mPThread = 0; return theAnswer; } On Sep 11, 2004, at 1:00 AM, darwin-development-request@lists.apple.com wrote: You are right here, in case of attached i don't use Semaphore technique. I gonna do some more testing with your hint about "detach" Also wanted to give one remark is that I'm doing QuickTime calls (but i use the EnterMoviesOnThread and Exit.... calls.... I also wanted to give one correction to my the code (and also matt code) I'm just doing this for the record so people that search archive: void* cOS_Thread::Entry(cOS_Thread* inCAPThread) { void* theAnswer = NULL; if(inCAPThread->mThreadRoutine != NULL) { #if FW_SEMAPHORE_WAIT_TECHNIQUE inCAPThread->mWaitSemaphore->Lock(); #endif theAnswer = inCAPThread->mThreadRoutine(inCAPThread->mThreadParameter); #if FW_SEMAPHORE_WAIT_TECHNIQUE inCAPThread->mThreadFinished = true; inCAPThread->mWaitSemaphore->Notify(); inCAPThread->mWaitSemaphore->Unlock(); #endif } inCAPThread->mPThread = 0; return theAnswer; } The signa/Notify l has to be in side the lock/unlock because if you are waiting for delete and the switch happens right after Unlock call... you delete the thread object (and also semaphore) before the notify code can be reached.... during testing this happened after 12 hours.... This email sent to site_archiver@lists.apple.com