Hi Loic,
Thanks for reviewing.
[...]
>> Setting the cancelability type to
>> .B PTHREAD_CANCEL_ASYNCHRONOUS
>> is rarely useful.
>> Since the thread could be canceled at
>> .I any
>> time, it cannot reserve resources (e.g., allocating memory),
>> acquire mutexes, semaphores, or locks, and so on,
>> since, when the thread is canceled,
>> the application has no way of knowing what the state of these resources
>> is;
>> that is, did the canceled thread manage to release the resources or not?
>> (Among other things, this means that clean-up handlers cease to be useful,
>> since they can't determine the state of resources that
>> they are intended to clean up.)
>> In general, most library functions, including most pthreads functions,
>> can't be safely called from an asynchronously cancelable thread.
>> (POSIX.1-2001 only requires that
>> .BR pthread_cancel (3),
>> .BR pthread_setcancelstate (),
>> and
>> .BR pthread_setcanceltype ()
>> be safe to call 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.
>
> 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.
> I
> don't pretend to compete with a native speaker, but find below a reworked
> version:
>
> Setting the cancelability type to *PTHREAD_CANCEL_ASYNCHRONOUS* is rarely
> useful. The cancelation could occur at any time, for instance in a middle of
> a library call, like malloc(), leaving possibly inconsistent state. The
> application is not aware of those internal library states, and as no
> possibly to recover from possible inconsistencies. That is, 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
> pthread_cancel(3), pthread_setcancelstate(3) and pthread_setcanceltype(3) to
> be async-cancel-safe. 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. 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
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
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.
Look okay to you?
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
