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-
chronously 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.
up to my comments above, yep.
Cheers,
Loïc.
--
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
