Actions

icon Post
text/html Subscribe
text/html Unsubscribe
CodeSourcery > List Archives
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Ted Baker <baker@xxxxxxxxxx>
  • Subject: Re: [c++-pthreads] What are the real issues?
  • From: Dave Butenhof <David.Butenhof@xxxxxx>
  • Date: Thu, 08 Jan 2004 06:51:47 -0500
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 ]---/