Re: For review: pthread_setcancelstate.3

[Loic Domaigne <tech-Z4JMKDdsf89Wk0Htik3J/w@public.gmane.org>]

Gidday Michael,


>> The paragraph is important, but I found it somewhat difficult to read.
> 
> Yes, I see.  There was at least one clumsy wording "Since...since"
> which made that over-long sentence had to parse.

[...]

> Thanks Loic.  I took some pieces of your suggestion, and arrived at
> the following
> 
>        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 mem-
>        ory with malloc(3)), acquire mutexes, semaphores, or locks, and
>        so  on.   Reserving  resources is unafe because the application

s/unafe/unsafe/

>        has no way of knowing what the state of these resources is when
>        the  thread is canceled; that is, did cancellation occur before
>        the resources were reserved, while they were reserved, or after
>        they  were  released?  Consequently, clean-up handlers cease to

worse: the invariant of some internal structures might get violated 
(e.g. if a list is used to manage chunk of memory malloc'ed, and the 
thread gets asynchronously canceled while updating the list).

>        be useful.  Functions that can be  safely  asynchronously  can-
>        celed  are  called  async-cancel-safe  functions.  POSIX.1-2001
>        only requires that pthread_cancel(3), pthread_setcancelstate(),
>        and  pthread_setcanceltype() be async-cancel-safe.  In general,
>        other library functions can't be safely called  from  an  asyn