From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4909 invoked by alias); 5 Mar 2005 21:41:25 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 4841 invoked from network); 5 Mar 2005 21:41:18 -0000 Received: from unknown (HELO quokka.dot.net.au) (202.147.68.16) by sourceware.org with SMTP; 5 Mar 2005 21:41:18 -0000 Received: from [202.147.82.57] (helo=ip-82-57.dot.net.au) by quokka.dot.net.au with esmtp (Exim 3.35 #1 (Debian)) id 1D7h1R-0005AH-00 for ; Sun, 06 Mar 2005 08:41:17 +1100 Subject: Re: Handle leak when using pthread mutex with win32 api threads From: Ross Johnson To: Pthreads-Win32 list In-Reply-To: References: Content-Type: text/plain Date: Sat, 05 Mar 2005 21:41:00 -0000 Message-Id: <1110058876.7988.19.camel@desk.home> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005/txt/msg00024.txt.bz2 On Sat, 2005-03-05 at 15:31 +0200, Dmitrii Sernii wrote: > I've made small corrections in test sample, so now mutex initialised > only once, and i've added pthread_mutex_destroy() function call. But > the problem still remains. > Here is two test applications - one of them uses API threads, and the > other pthreads. Program with pthreads don't have any leaks, while > program with API threads produces lots of them. > Are you dynamic or static linking? If you're using the pthreads dll then there would seem to be a problem in the library. If you're static linking then read on ... The library will be automatically creating POSIX thread handles (with DETACHED status) because the pthread_mutex_lock() call needs a pthread ID to track recursive mutex ownership. These pthread IDs are cleaned up by the pthreads dll.c dllMain() switch. This cleanup doesn't happen automatically when static linking, in which case it's necessary to explicitly run the cleanup. There are four routines provided for this (see README.NONPORTABLE for details):- BOOL pthread_win32_process_attach_np (void); BOOL pthread_win32_process_detach_np (void); BOOL pthread_win32_thread_attach_np (void); BOOL pthread_win32_thread_detach_np (void); Regards. Ross > //program with handle leaks > #include > #include > #include > > pthread_mutex_t mutex(PTHREAD_RECURSIVE_MUTEX_INITIALIZER); > > DWORD WINAPI threadProc(void *param) > { > pthread_mutex_lock(&mutex); > pthread_mutex_unlock(&mutex); > return 0; > } > > void main() > { > const int max_threads = 500; > DWORD id; > HANDLE th[max_threads]; > int i; > for (i=0;i th[i]=CreateThread(0,0,threadProc,0,0,&id); > > for (i=0;i { > WaitForSingleObject(th[i],INFINITE); > CloseHandle(th[i]); > } > pthread_mutex_destroy(&mutex); > getch(); > } > > ========================== > > //program without handle leaks > #include > #include > #include > > > pthread_mutex_t mutex(PTHREAD_RECURSIVE_MUTEX_INITIALIZER); > > void* threadProc(void *param) > { > pthread_mutex_lock(&mutex); > pthread_mutex_unlock(&mutex); > return 0; > } > > void main() > { > const int max_threads = 500; > DWORD id; > pthread_t th[max_threads]; > int i; > > for (i=0;i pthread_create(&(th[i]),0,threadProc,(void*)i); > > for (i=0;i pthread_join(th[i],(void**)&id); > > pthread_mutex_destroy(&mutex); > getch(); > } > > Best regards, > Dmitrii Sernii >