From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25519 invoked by alias); 9 Mar 2004 14:15:51 -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 25511 invoked from network); 9 Mar 2004 14:15:49 -0000 Received: from unknown (HELO saladin.atlantis.sk) (212.89.225.177) by sources.redhat.com with SMTP; 9 Mar 2004 14:15:49 -0000 Received: (qmail 20829 invoked from network); 9 Mar 2004 14:15:51 -0000 Received: from proxy.posam.sk (HELO manabove.org) (62.168.66.74) by saladin.atlantis.sk with AES256-SHA encrypted SMTP; 9 Mar 2004 14:15:51 -0000 Message-ID: <404DD193.4060303@manabove.org> Date: Tue, 09 Mar 2004 14:15:00 -0000 From: Brano Kemen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: pthreads-win32@sources.redhat.com Subject: Re: problem using pthread_cancel and pthread_mutex_lock References: <4047B840.5000509@callisto.canberra.edu.au> In-Reply-To: <4047B840.5000509@callisto.canberra.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00024.txt.bz2 Ross Johnson wrote: > There is another reason to avoid async cancelation that is specific to > pthreads-win32: this implementation only approximates async cancelation > because it relies on the thread actually running at some point after > cancelation. So if your thread is blocked on a resource at the time that > it's async canceled, it won't actually exit until it's unblocked in some > way to resume execution (at which point it will exit immediately) - and > if you can do that then you don't need async cancelation anyway. > Unfortunately, the time you're most likely to really need an async > cancel - to kill a thread blocked on a system resource that you can't > unblock - is the very time it won't work in pthreads-win32, and if it > did work, as in does in other implementations, then you'd probably be > creating a resource leak. So it's hard to find a good argument for async > cancel. There's one thing that can help with the blocked threads in windows. It's the undocumented "NtAlertThread" function that is exported from ntdll.dll, that apparently wakes up the thread even when blocked (listening on socket etc.), so it would run the injected cancelation code. We use async cancelation in our project (http://coid.sourceforge.net) without problems. On a related note - I think there's bug in pthread_cancel.c in the 'else' block starting at line 146. Thread is suspended, and then checked with WaitForSingleObject(threadH, 0) if it did not exit already. But if it did, the thread->cancelLock (locked at line 129) is never unlocked back. brk