From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5847 invoked by alias); 9 Mar 2004 15:42:07 -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 5830 invoked from network); 9 Mar 2004 15:42:06 -0000 Received: from unknown (HELO saladin.atlantis.sk) (212.89.225.177) by sources.redhat.com with SMTP; 9 Mar 2004 15:42:06 -0000 Received: (qmail 11220 invoked from network); 9 Mar 2004 15:42:09 -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 15:42:09 -0000 Message-ID: <404DE5CD.7050102@manabove.org> Date: Tue, 09 Mar 2004 15:42: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> <404DD193.4060303@manabove.org> <003801c405e0$32c91a70$6b64fe83@lesvos> In-Reply-To: <003801c405e0$32c91a70$6b64fe83@lesvos> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00026.txt.bz2 It surely would be more useful than the current async. cancellation code, but would it help in this particular case? If the thread is waiting on a socket, the APC(ex) won't be executed until the thread voluntarily returns from kernel. Am I right? NtAlertThread does apparently wake the thread up even there, although we tested it just with sockets and sleeps (and pthread's injected cancellation code). brk Panagiotis E. Hadjidoukas wrote: > In general, don' t you agree that an "official" extension of QueueUserAPC > (e.g. QueueUserAPCEx, that automatically sets the target thread in alertable > state) > would be very useful? > > Panagiotis > > > > ----- Original Message ----- > From: "Brano Kemen" > To: > Sent: Tuesday, March 09, 2004 4:15 PM > Subject: Re: problem using pthread_cancel and pthread_mutex_lock > > > >> >>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