This is the mail archive of the
mailing list for the pthreas-win32 project.
Re: problem using pthread_cancel and pthread_mutex_lock
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).
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
would be very useful?
----- Original Message -----
From: "Brano Kemen" <firstname.lastname@example.org>
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
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)
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.