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