Re: For review: pthread_setcancelstate.3

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

Hi Michael,

Looks good to me.

Loïc.
--

> Hi Loic,
> 
> On Mon, Nov 24, 2008 at 3:56 PM, Loic Domaigne <tech-Z4JMKDdsf89Wk0Htik3J/w@public.gmane.org> wrote:
>> 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/
> 
> Fixed.
> 
>>>       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).
> 
> Yes, maybe it's worth emphasizing that.  I added a sentence, so now we have:
> 
>        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 unsafe because the application
>        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?  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
>        cancellation 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 only requires that pthread_can