> Also, don’t you have to hit a pthread cancellation point for pthread_cancel to take effect?

No, the whole point here is async cancellation - you don't test for it and you don't enter a cancellation point.

Excerpt from pthread_setcancelstate(3):

  >    Asynchronous cancelability
  >        Setting the cancelability  type  to  PTHREAD_CANCEL_ASYNCHRONOUS  is  rarely  useful.
  >        Since  the  thread  could be canceled at any time, it cannot safely reserve resources
  >        (e.g., allocating memory with malloc(3)), acquire mutexes, semaphores, or locks,  and
  >        so  on.   Reserving resources is unsafe because the application has no way of knowing
  >        what the state of these resources is when the thread is canceled; that is, did cance-
  >        lation occur before the resources were reserved, while they were reserved,  or  after
  >        they  were  released?   Furthermore,  some internal data structures (e.g., the linked
  >        list of free blocks managed by the malloc(3) family of functions) may be left  in  an
  >        inconsistent  state if cancelation occurs in the middle of the function call.  Conse-
  >        quently, clean-up handlers cease to be useful.
  >
  >        Functions that can be safely asynchronously  canceled  are  called  async-cancel-safe
  >        functions.   POSIX.1-2001  and  POSIX.1-2008  require  only  that  pthread_cancel(3),
  >        pthread_setcancelstate(), and pthread_setcanceltype() be async-cancel-safe.  In  gen-
  >        eral,  other  library  functions can't be safely called from an asynchronously cance-
  >        lable thread.
  >
  >        One of the few circumstances in which asynchronous cancelability  is  useful  is  for
  >        cancelation of a thread that is in a pure compute-bound loop.