Hi Loic,
On Mon, Nov 24, 2008 at 3:56 PM, Loic Domaigne <tech@xxxxxxxxxxxx> 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-
cel(3), pthread_setcancelstate(), and pthread_setcanceltype()
be async-cancel-safe. In general, other library functions
can't be safely called from an asynchronously cancelable
thread. One of the few circumstances in which asynchronous
cancelability is useful is for cancellation of a thread that is
in a pure compute-bound loop.
Thanks Loic.
Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
