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

At Sun, 16 Jan 2011 22:17:04 +0100, Gaetano Mendola wrote:

On 16/01/2011 17:47, Dave Abrahams wrote:

...

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

Are you sure?

Quite.

I remember to have read the requirement for DTOR no-throw in the c++0x.

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#219

That's an OPEN issue; it proves nothing about what's (been) in the draft. -- Dave Abrahams BoostPro Computing http://www.boostpro.com