这是一个基本问题，但答案似乎是在逃避我。无论如何，这是背景信息：
根据手册页，pthread_cancel()的返回值如下：
成功时，pthread_cancel（）返回0;如果出错，它会返回一个 非零错误号。
根据要取消的线程的取消状态，它可能会立即终止，或者请求可能会排队。在我的情况下，取消将被推迟，并将通过一些清理处理程序。在我的主线程中，我想验证返回值。也就是说，一种简单的方法是添加一行，例如
assert(pthread_cancel(tID));
据我所知，如果请求成功排队，pthread_cancel()似乎只返回0而不是线程被取消。换句话说，上面的代码行是否会阻塞？我担心的是，如果我误解了手册页，并且我在子线程中有一个特别长的延迟期，我的主线程将被卡在断言上，因为pthread_cancel()正在阻塞。
答案 0 :(得分：1)
pthread_cancel()永远不会阻止。它也不会告诉你，线程是否被成功取消。
在延迟模式下：它只是设置一个标志（取消请求），有问题的线程必须主动查询（可能隐含在系统调用中），然后线程将合作退出。
在模式异步中：线程将在任何时间点（通常是立即）被取消。这在纯CPU绑定循环中是安全的，不会调用任何系统或库函数，甚至不能直接或间接分配内存。请注意，如果线程使用互斥锁或其他相关线程基元与其他线程同步，这也是不安全的，因为取消线程会使所有互斥锁处于未定义状态。
简而言之：异步取消通常是不安全的，设计上不干净，通常应该避免。只有极少数用例可以以干净的方式使用（例如，100％CPU绑定代码仅通过获取/释放语义与其他线程通信（无锁））。
答案 1 :(得分：0)
从我的手册页：
目标线程中的取消处理与从pthread_cancel（）返回的调用线程异步运行。
所以是的，你的断言不会阻止。