Re: [c++-pthreads] Restating the Jason model

[Dave Butenhof <David.Butenhof@xxxxxx>]

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@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 ]---/