pthread_cancel and EH: let's try this again

Alexander Terekhov terekhov at web.de
Mon Jul 18 00:20:10 UTC 2005


Wil Evers wrote:
[...]
>      {
>        cancellation_manager enabler(true);
>        some_cancellation_point();
>      }

Never do that in "library" code.

http://www.opengroup.org/onlinepubs/009695399/functions/pthread_setcancelstate.html

<quote>

RATIONALE

The pthread_setcancelstate() and pthread_setcanceltype() functions control 
the points at which a thread may be asynchronously canceled. For 
cancellation control to be usable in modular fashion, some rules need to 
be followed.

An object can be considered to be a generalization of a procedure. It is a 
set of procedures and global variables written as a unit and called by 
clients not known by the object. Objects may depend on other objects.

First, cancelability should only be disabled on entry to an object, never 
explicitly enabled. On exit from an object, the cancelability state should 
always be restored to its value on entry to the object.

This follows from a modularity argument: if the client of an object (or the 
client of an object that uses that object) has disabled cancelability, it is 
because the client does not want to be concerned about cleaning up if the 
thread is canceled while executing some sequence of actions. If an object is 
called in such a state and it enables cancelability and a cancellation 
request is pending for that thread, then the thread is canceled, contrary to 
the wish of the client that disabled.

Second, the cancelability type may be explicitly set to either deferred or 
asynchronous upon entry to an object. But as with the cancelability state, 
on exit from an object the cancelability type should always be restored to 
its value on entry to the object.

</quote>

regards,
alexander.

P.S. http://groups.google.de/group/comp.lang.c++.moderated/msg/c897f898de7a97cd




More information about the c++-pthreads mailing list