summaryrefslogtreecommitdiff
path: root/FAQ
diff options
context:
space:
mode:
authorrpj <rpj>2000-01-05 10:01:20 +0000
committerrpj <rpj>2000-01-05 10:01:20 +0000
commit05d85f1763459eeb5d6cfc4a2616f5a09e0115ad (patch)
treedf5e8ba67c8dfb76c17697d90e1ecfe89c097a6a /FAQ
parentb7406ad24abe4a1992b4e809b8bec867675091bb (diff)
Update the FAQ question 4 for async cancelation.
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