[c++-pthreads] Restating the Jason model

[Dave Butenhof]

Alexander Terekhov wrote:

>Dave Butenhof wrote:
>[...]
>  
>
>>Absolutely; because the correct behavior of the application (which might
>>be distributed) could depend on being able to notify the remote partner
>>that the local thread is shutting down. Nathan's proposal doesn't allow
>>that, and that's the big weakness.
>>    
>>
>Nathan's proposal does allow that (not that I really like Nathan's 
>proposal). You'd simply have to manually disable cancelation. Think of 
>"traditional" pthread_cleanup_pop(!0) handlers.
>  
>
Only if the code was specifically aware of cancellation and the 
consequences. But it seems that the primary basis for Nathan's proposal 
(and the only real justification I can see) was the idea that 'if 
(error) {cleanup(); return error;}' idiom in existing C code would 
continue to work despite cancellation. And that's simply not true; in 
general you'd need to re-code cleanup() to disable cancellation. (And at 
least all such would need to be analyzed carefully to ensure that 
cleanup() didn't call any cancellation points.)

>>Jason's proposal will cause the cancel to be re-asserted when the
>>exception object is destroyed, on exit from the catch(), after local
>>cleanup has been done. This makes the catch() behave (more or less) like
>>a destructor.
>>    
>>
>And that's "the big" weakness. catch() != destructor.
>  
>
Unfortunately, there's apparently an extremely common (and perhaps even 
officially recommended) IDIOM in C++ that implements non-object-specific 
"destructors" using catch(...). It appears that there's general 
consensus here for a plan that retains this idiom, and I can understand 
that desire. While I don't really like the idea of "sticky cancel", I 
don't yet see another practical alternative that addresses the basic 
problem without redesigning C++. (Of course, it's fine for you to bring 
this up, though I think you harp on it too much; if the C++ committee IS 
interested in considering a massive redesign of C++ exceptions, this 
would be a good time.)

>void operation() throw(std::thread_cancel_request);
>
>void f() {
>  try {
>    operation();
>  } 
>  catch(...) {
>    pthread_exit("Wow, canceled."); // or something like that
>  }
>  /* ... */
>}
>  
>
Given that pthread_exit() is also an exception, there's little 
difference between this and "throw my_fancy_exception". (Aside from the 
fact that unlike my_fancy_exception, the thread exit exception is also 
designated as "thread terminating".)

-- 
/--------------------[ David.Butenhof at hp.com ]--------------------\
| 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 ]---/