Re: [c++-pthreads] Re: thread-safety definition

[Dave Butenhof <David.Butenhof@xxxxxx>]

Wil Evers wrote:

> Dave Butenhof wrote:
>
> > But I think I also understand what you mean; and the problem isn't 
> > with the model, but rather with the effect of that model on existing 
> > code that all-too-casually and agressively eats exceptions it doesn't 
> > understand. I think there are vanishingly few circumstances where a 
> > blind catch(...) without an unconditional re-throw should be 
> > considered "legitimate". If you don't completely understand what an 
> > exception means, you cannot claim to have completely recovered, and 
> > therefore cannot reasonably finalize propagation. (And when you catch 
> > anonymously, you can't possibly understand what they mean since you 
> > can't even identify them.) 
>
> Let me try again.
>
> Doing a blind catch(...) without an unconditional rethrow is not 
> always a matter of sloppiness.  Sometimes, the only alternative is a 
> crash - the C++ standard clearly says that a second exception escaping 
> from a destructor invoked by the stack unwinding machinery will result 
> in program termination.  There is nothing the poor programmer can do 
> about this.
>
> To reiterate: a few days ago, I posted the following example -
>
>   remote_resource_holder::~remote_resource_holder()
>   {
>     remote_resource->release();
>   }
>
> Now what do you suggest I should do when an exception (say, a 
> networking error, but it might just as well be a cancellation request) 
> is thrown from somewhere within remote_resource->release()?  The way I 
> see it, either the original exception or the one that was just thrown 
> at me will have to be finalized.

Again, I don't think it should be possible to have cancellation within a 
destructor unless the destructor "does something special and unusual". 
In your example, you might want to make the release message cancellable, 
because the remote release might take a long time. Depends on the 
consequences of abandoning that particular remote resource, I suppose. 
If you did choose to make it cancellable, then, yes, you'd need to 
finalize the cancel within the destructor to avoid confusing propagation 
problems; which means that it needs to resurface later. This does tend 
to favor Jason's model. I remain vaguely uncomfortable with the notion 
of automatically re-pending the cancel at the right points, but I never 
intended to pretend to having any certain knowledge that there really 
are problems. ;-)

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