Apple的文档以及我能找到的所有开源实现都同意线程取消应该完全由用户处理。也就是说，[thread cancel]只在接收器上设置BOOL属性。然后由用户的实现来定期检查[NSThread currentThread].isCancelled，如果YES，则过早地从线程的main方法返回。
好的，够公平的。但是为什么不依靠pthread_cancel，它已经实现了几十个内置的取消点？当然，这将产生更具响应性的线程取消。 NSThread可以很容易地扩展为具有cancellationBlock属性，或用于NSThread本身可以通过pthread_cleanup_pop发送的用户定义的取消行为的其他机制。
Apple认为这对于人们使用或其他东西来说太复杂了吗？ NSThread API的其余部分基本上是{1}} API的1：1，所以我很好奇为什么在这里选择了不同的（诚实的天真）路径。