summaryrefslogtreecommitdiff
path: root/FAQ
diff options
context:
space:
mode:
Diffstat (limited to 'FAQ')
-rw-r--r--FAQ16
1 files 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