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

[Alexander Terekhov <boo@xxxxxxxxxxx>]

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.)

Agreed. 

> 
> >>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. 

That idiom is known as catch/re-throw. It does re-throw. Jason's 
sticky cancel is meant to "address" the problem of broken iostream 
stuff which doesn't re-throw.

regards,
alexander.