From 05d85f1763459eeb5d6cfc4a2616f5a09e0115ad Mon Sep 17 00:00:00 2001 From: rpj Date: Wed, 5 Jan 2000 10:01:20 +0000 Subject: Update the FAQ question 4 for async cancelation. --- FAQ | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) (limited to 'FAQ') diff --git a/FAQ b/FAQ index 5df87ac..426e92c 100644 --- a/FAQ +++ b/FAQ @@ -211,17 +211,17 @@ A 4 > calls work. The answer to your first question is, normal POSIX behaviour would -be to asynchronously cancel the thread. +be to asynchronously cancel the thread. However, even that doesn't +guarantee cancelation as the standard only says it should be +cancelled as soon as possible. However ... -Pthreads-win32 doesn't support asynchronous cancelation, only -deferred, which is also very limited. The reason there is no async -cancelation is that it's too hard, if not impossible, to implement -on top of Win32. Incidently, Butenhof "Programming with POSIX -Threads" recommends not using async cancelation because the -possible side effects are unpredictable, especially if you're -trying to write portable code. +Pthreads-win32 only partially supports asynchronous cancellation. If the +thread you're trying to cancel is blocked (for instance, it could be waiting +for data from the network), it will only get cancelled when it unblocks +(when the data arrives). Unfortunately, there is no way to do so from +outside the thread. Using deferred cancelation would normally be the way to go, however, even though the POSIX threads standard lists a number of C library -- cgit v1.2.3