Re: [boost] [Thread] thread::interrupt of the death

Subject: Re: [boost] [Thread] thread::interrupt of the death
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-01-16 11:47:58

At Sun, 16 Jan 2011 16:46:09 +0100,
Gaetano Mendola wrote:
> 
> On 16/01/2011 14:28, Dave Abrahams wrote:
> > At Sun, 16 Jan 2011 09:20:38 +0100,
> > Gaetano Mendola wrote:
> >>
> >> Hi all,
> >> I think a thread after getting an interrupt the first think to do
> >> before to throw a boost::thread_interrupted (passing or being on an
> >> interruption point) has to disable interruption, indeed think what
> >> happens if during a stack unwinding the thread passes again on an
> >> interruption point and it receives a second interrupt.
> >> This scenario is not that hard to happen.
> >
> > 1: is this the behavior in the draft standard?
> 
> Are you talking about threads in the standard or throwing while a stack
> unwinding?
> AFAIK c++0x standard doesn't provide a method to interrupt a thread 

Oh, right, we punted because the POSIX people were jumping up and down
about how interruption was non-negotiable and non-ignorable even
though it can be suppressed and/or ignored even in C. :(

> to the other side for the draft 

I don't understand that part of the sentence.

> having code that can throw inside the DTOR is a compile time error.

The draft has never had language deeming potential throwing from
inside a DTOR ill-formed.

> > 2: is it important to special-case for thread interruption?  It's
> >     still going to be true that you can't call anything that might
> >     throw during stack unwinding (including during thread
> >     interruption), a more general case of the same scenario.
> 
> Well, I have come to this conclusion because my own application uses
> third party libraries and 2 of those are based on boost thread. My
> application was crashing because after have interrupted (twice) my
> instantiated thread  during the stack unwinding those two libraries
> where performing a thread_group::join_all.
> 
> I have already asked them to fix they own code (gnuradio to mention one
> library) but the source of the issue is the fact that boost::thread
> reacts again with a throw at the second interrupt received instead to
> ignore it.

I'm not sure you can say that is the underlying cause.  I don't object
to the change you're proposing, but I don't want to make it "for the
wrong reasons" or with an expectation that it fixes more than it
actually does.  The other libraries called a function that could throw
during stack unwinding.  That seems like a very fundamental problem to
me.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com