From 05d85f1763459eeb5d6cfc4a2616f5a09e0115ad Mon Sep 17 00:00:00 2001
From: rpj <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(-)

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