You put the check outside the innermost loop. Put it up one or two loops instead, and reason that the check runs frequently enough and also infrequently enough.

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

Those are way more expensive than a branch, but if you want the exact behavior, you could do “if (done) { break; } else { pthread_??? }”

> 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.