[cpp-threads] Interruption (was: Asynchronous FunctionProposal)

Howard Hinnant hinnant at twcny.rr.com
Thu Jun 4 00:25:09 BST 2009


On Jun 3, 2009, at 7:03 PM, Boehm, Hans wrote:

>> -----Original Message-----
>> From:  Howard Hinnant
>>
>> On Jun 3, 2009, at 6:06 PM, Boehm, Hans wrote:
>>
>> interrupt & join, or at least interrupt & wait for
>> acknowledgement of interrupt would make excellent ~thread()
>> semantics in my opinion.  The only time ~thread() should have
>> any work to do is when it executes during exception-driven
>> stack unwinding.  However if there is no
>> interrupt-and-don't-wait, then the following code is going to
>> have extremely poor performance:
>>
>> vector<thread> v;
>> try
>> {
>>    ...
>> }
>> catch (std::ive_been_interrupted&)
>> {
>>    for (auto i = v.begin(); i != v.end(); ++i)
>>         i->interrupt();                 // I don't want to wait here
>>    for (auto i = v.begin(); i != v.end(); ++i)
>>         i->join();                      // I want to wait
>> here instead
>>    throw;                               // All v-threads should
>> interrupt in parallel, not sequentially
>> }
>>
>> If you put too many seat belts in the car, the driver won't
>> be able move enough to safely drive it.  There has to be a
>> reasonable compromise between safety and functionality.
>> Especially if we're threading for performance reasons.
> Good point.  And if there's a chance of getting the car without all  
> the extra seat belts, I agree.  But if all we can get is  
> interrupt_and_join(), is that better than no car?  Is this less  
> troubling to people than the other proposals?
>
> (It still means that you need to use loops with timeouts or the like  
> on I/O to make a thread interruptable.  But that seems far better  
> than what we have now.)

If boost::thread (or any other widely available and free C++ library)  
has a compelling feature that std::thread doesn't, and not vice-versa,  
then it really doesn't make any difference if std::thread is half as  
good as boost::thread or 2/3 as good as boost::thread.  std::thread  
will be still-born.  If someone comes up to you for advice, and asks  
you why they should use std::thread instead of boost::thread, what  
would you tell them?  <shrug>

Maybe if they are sure they won't need interruption, and are sure that  
their ~thread() will never execute under exceptional conditions, then  
maybe std::thread is more convenient than boost::thread.  That's a  
pretty weak argument.

-Howard




More information about the cpp-threads mailing list