From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 805 invoked by alias); 20 Mar 2009 23:37:35 -0000 Received: (qmail 795 invoked by uid 22791); 20 Mar 2009 23:37:34 -0000 X-SWARE-Spam-Status: No, hits=0.5 required=5.0 tests=BAYES_40,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from smtp.virginbroadband.com.au (HELO smtp.virginbroadband.com.au) (123.200.191.11) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Mar 2009 23:37:27 +0000 Received: from [119.12.171.180] (unknown [119.12.171.180]) by smtp.virginbroadband.com.au (Postfix) with ESMTP id 6C820704005E for ; Sat, 21 Mar 2009 10:37:23 +1100 (EST) Message-ID: <49C427D7.3090505@homemail.com.au> Date: Fri, 20 Mar 2009 23:37:00 -0000 From: Ross Johnson User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: pthreads-win32@sourceware.org Subject: Re: Pthread_join waits endlessly for already ended thread References: <49C192FE.8070809@homemail.com.au> <00c801c9a889$66077340$321659c0$@com.br> In-Reply-To: <00c801c9a889$66077340$321659c0$@com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2009/txt/msg00018.txt.bz2 Virgilio Alexandre Fornazin wrote: > I had a problem similar to this, and creating an event handle for signaling > solves nothing. > > I had this problem in plain win32 threads before. This always happened in > DLL_PROCESS_DETACH. > It´s probably a bad design / limitation in win32 shared library model. The > cause, if I remember, > is that the heap is locked in some way that functions related to thread > (TerminateThread if I'm > not missing other) must access this heap, then it deadlocks in some locking > Windows have internally. > This is good to know in case all else fails. The library does have a compile-time condition that will cause threads to enter/exit via _beginthread()/_endthread() rather than the preferred _beginthreadex()/_endthreadex() versions, and MS documentation does say that _endthread() closes the Win32 thread handle resulting in no signalling, e.g. to WaitFor*(). This is one case that does exist in the library and needs to be fixed unless I'm mistaken. The pre-built pthreads-win32 DLLs should be using _endthreadex() but in this case it is still the exiting thread that explicitly closes the Win32 thread handle before _endthreadex() is called. I'd like to move that close to the joining thread.