Re: [c++-pthreads] What are the real issues?

[Dave Butenhof <David.Butenhof@xxxxxx>]

Ted Baker wrote:

> > But as I said, I think the really fundamental issue is whether a thread 
> > should be allowed to receive a cancellation request, start to do some 
> > work as a result of the request, and then decide that it doesn't want 
> > to be cancelled.  If we think that's reasonable then I think what we 
> >    
> POSIX and the SUS do not define this.  I believe it would be an
> upward-compatible extension to define it.  That is, no existing
> UNIX/POSIX conformant application could be broken by an extension
> that extends the API to allow a thread to regain control and
> "revoke" a cancellation, since no conformant application could
> presently include such an API call
>  
The POSIX cancellation cleanup mechanism was designed to be implemented 
easily on top of a native exception mechanism. With the full expectation 
that these exceptions could ALSO be handled (and finalized, if desired) 
by native exception syntax -- such as C++ catch, or the C SEH "except" 
extension. While such extensions are beyond the scope of POSIX, there's 
no contradiction. (Any application using this is at best "conforming 
with extensions" rather than "strictly conforming"; but that distinction 
is of little interest to most developers. Since no "strictly conforming" 
application can exercise these extensions, or be affected by them, the 
extension doesn't affect the conformance of the IMPLEMENTATION.)

This was in fact a requirement placed on our initial DCE thread 
implementation by the OSF DCE team. They wanted to be able to write 
server management threads that would call the application's RPC server 
code and be able to trap APPLICATION-level cancellation of the server 
activity. Such a cancel (generally reflected from the client process) 
would terminate the APPLICATION server code exactly like a normal cancel 
(because it is), but wouldn't affect the "management infrastructure" 
because the routine that called the application server would have 
something like a FINALLY or CATCH_ALL clause (like a C++ "catch (...)").

There would have been other design alternatives, and there's certainly 
room to question whether this example validates the concept. 
Nevertheless, there are potential justifications for this sort of thing, 
and I've never seen any reason to disallow it.

> However, the debate will be over one *wants* to export such
> functionality.
>  
My take on that can probably be inferred from my comments above. The 
only reasonable implementation of cancellation is as an exception -- it 
was, after all, designed and intended to be implemented that way. Once 
that's done, I see no reason to artificially prevent specialize 
applications from handling it as any other exception. There are, 
however, certain arguments in favor of Ted's description of gnat 
behavior; that the code must do something special to declare that it 
really wants to handle this class of exception. The capability might be 
generally packaged as something like a subclass hierarchy designating 
"exceptions that should always terminate", which can only be finalized 
by naming the sub-hierarchy or some particular exception within (e.g., 
catch(...) might implicitly re-throw).

--
/--------------------[ David.Butenhof@xxxxxx ]--------------------\
| Hewlett-Packard Company       Tru64 UNIX & VMS Thread Architect |
|     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/