Why is destructor of boost::thread detaching joinable thread instead of calling terminate() as standard suggests?

According to the draft C++0x standard, this code:

void simplethread()
{
    boost::thread t(someLongRunningFunction);
    // Commented out detach - terminate() expected.
    // t.detach();  
}

... should result in an terminate() call, but in current (boost 1.46.1) implementation of boost threads it doesn't, thread simply gets detached in destructor and continues on.

My question is: why?

I thought boost::thread is as much inline with draft stand开发者_Python百科ard as it gets.

Is there a design reason for this? Will it be changed in future versions of boost::thread?

The reason is largely historical. boost::thread came first. The proposals for std::thread were derived from boost::thread and originally had the behavior that boost::thread does now.

However during the standardization process a significant number of people wanted std::thread::~thread() to join() in the destructor if not already joined, instead of detach(). The arguments were made for each side and the votes were taken. 50/50. More arguments were made and more votes were taken. Some people were swayed to the other position. But still 50/50.

Someone (I don't recall who) suggested terminate(). Votes were taken and though it wasn't unanimous in favor (I couldn't vote for it), it did receive enough of a majority to be called consensus.

I imagine boost::thread never changed because it had an installed user base and no one wants to unnecessarily break code for that user base.

Edit:

Ah, Rob points us to the original of this duplicate question and that answer points to N2802 which includes rationale.

I should also note that the original proposal for std::thread had thread cancellation, and ~thread() would cancel the unjoined-thread and then detach it, which made a lot of sense. This code path would normally only be chosen when the parent thread was unwinding due to an exception.