What are pthread cancelation points used for?

Question

There is discussion of pthread cancellation points (http://man7.org/linux/man-pages/man3/pthread_cancel.3.html) on several question. In some cases the respondents say that cancellation points should not be used unless the programmer knows what they are doing very well.

My question---what are pthread cancellation points used for?

[updated from comment]

1. Does a cancellation point allow those specific API calls to be canceled?
2. Why those and not others?
3. Would anyone want to use them for anything else?
4. Are they a hack to deal with a problem in the kernel, or are they inherent in something having to with POSIX?
5. Would you want to use cancellation points in user-level code or just in APIs?

Answer 1

Does a cancellation point allow those specific API calls to be canceled?

Sticking with PTHREAD_CANCEL_DEFERRED, this may be the the center of the confusion. You are almost thinking of it backwards. A cancellation point doesn't allow system calls (API in your nomenclature) to be canceled, the calls check whether a cancellation request is pending. Conceptually you can think of this as (manually) setting a switch. The automatic cancellation points will check if it is in effect and a deliberate call to pthread_testcancel can be inserted where convenient or otherwise necessary - for instance, in the middle of a long running calculation loop where there might not otherwise be cancellable system calls. The cancellation points automatically force calls to any pthread cleanup handlers that were set up and which can be chained in a manner similar to atexit calls.

A lot of people choose (if it is workable for their situation) to set their own switch and code a means of shutting down the thread at that point in the thread when they check the switch. PTHREAD_CANCEL_DEFERRED is basically that on steroids. It provides (potentially) several points where that switch is conceptually check and thereby also forces the developer to consider the implications of being canceled at every one of those points.

Why those and not others?

You would need to discuss this on a call by call basis but primarily because of unpredictable side effects.

Would you want to use cancellation points in user-level code or just in APIs?

Yes, you want to use them in user-level code. You as the programmer are in the best position to know what resources you are using and how to clean them up if the thread is canceled and the logical implications of cancelization at any given point.

PTHREAD_CANCEL_ASYNCHRONOUS is another ball of wax and nightmare of its own. Conceptually you can almost think of this as the thread getting blasted by a kill signal - it can be interrupted anywhere - but it does provide the opportunity for the cleanup handlers to run. The problem is that it is really hard to do that e.g. what if it is canceled in the middle of a malloc? This makes it pretty much useless outside of some really, really, carefully considered situations.

Answer 2

... what are pthread cancellation points used for?

From man 7 pthreads:

Cancellation points

POSIX.1 specifies that certain functions must, and certain other functions may, be cancellation points.

More:

If a thread is cancelable, its cancelability type is deferred, and a cancellation request is pending for the thread, then the thread is canceled when it calls a function that is a cancellation point.

Referring the questions:

1. The API functions defined by POSIX here: http://man7.org/linux/man-pages/man7/pthreads.7.html (Cancellation Points) either are cancellations points or may be some.
2. To introduce a (user-) specific cancellation point call pthread_testcancel() where you feel it might be necessary.
3. No.
4. They are defined by POSIX to provide a standardise way to handle the way cancellation might happen. This especially makes sense for blocking functions.
5. see 2.

As a final note: Avoid cancellation of threads whereever possible, as it might lead to unexpected and unreproducable behaviour of a program. Try to always design a program to be able to gracefully shut it down by ending all threads without explicit calling pthread_cancel().