Re: problem using pthread_cancel and pthread_mutex_lock

[Brano Kemen <cameni@manabove.org>]

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" <cameni@manabove.org>
> To: <pthreads-win32@sources.redhat.com>
> 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