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

[Alexander Terekhov <boo@xxxxxxxxxxx>]

Ted Baker wrote:
> 
> On Mon, Jan 12, 2004 at 07:19:42PM +0100, Alexander Terekhov wrote:
> > Ted Baker wrote:
> > [...]
> > > There is no need for a destructor to be aware of cancellation.
> >
> > my_file::~my_file() throw() {
> >   fclose(/*...*/); // doesn't throw; cancel is unexpected (even if thread
> >                    // cancel state is equal here to PTHREAD_CANCEL_ENABLE)
> > }
> 
> Yes, in my model, cancel state would *always* be equal to
> PTHREAD_CANCEL_DISABLE in the my_file (and my_other_file)

And I say that this sucks.

> destructors, and so fclose() cannot throw cancellation.
> 
> > void jason() throw() {
> >   std::enable_thread_cancel(); // re-enable cancel state
> >   std::thread_self().cancel(); // re-inject cancel request
> > }
> 
> > my_other_file::~my_other_file() throw() {
> >   bool canceled_before = std::unwinding<std::thread_cancel_request>(this);
> >   try {
> >     if (canceled_before) jason();
> >     fclose(/*...*/); // can (should "if (canceled before)") throw
> >     /*std::*/pthread_testcancel(); // fix "may occur" mess
> >   }
> >   catch (std::thread_cancel_request const &) {
> >     if (!canceled_before) jason();
> >   }
> > }
> 
> What is the purpose of the above?  That is, why are you
> intentionally shooting yourself in the foot, by enabling
> cancellation and then explicitly catching it in ~my_other_file()?

Because I want to interrupt fclose (the flushing part of it, of course).

> I guess you have a reason, but I don't see it.  This seems to just
> makes ugliness without any apparent benefit.  You can just call
> fclose() by itself (without the thry...catch), since cancellation
> is disabled, as in ~my_file().
> 
> (BTW, I would prefer to see code that does this sort of explicit
> playing with cancellation state and catching of cancellation
> required to provide some sort of syntactic override, so that
> people are less likely to inadvertently shoot their feet.)
> 
> > Now, in your model with cancellation ALWAYS disabled while running
> > destructors (not only when acting upon a cancel request delivery...
> > thread_exit aside for a moment), I'd have to add enable/disable RAII
> 
> Please translate "RAII" for me?

http://www.terekhov.de/DESIGN-futex-CV.cpp

> 
> > guard object (and that's in addition to save-disable/restore internal
> 
> Why do you say that would require you to add a guard object?

See above.

regards,
alexander.