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

[Boehm, Hans]

> 
> 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>
If std::thread had interrupt_and_join and boost::thread also has interrupt(), I suspect I'd still go with std::thread, just because it's in the standard, and my code is not likely to be sensitive to the performance of mass thread interruption.  (In the case of IO, where you might actually have to wait for timeouts, you could still complement this with your own convention to get the Boost performance back, I think.)  But I agree this only makes sense if interrupt_and_join() is more acceptable to the committee than interrupt().  On purely technical grounds, I'd personally probably go with the Boost interface and a note warning that you also need to call join().
> 
> 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.
Actually, I think destructors are currently a strong argument in favor of std::thread over boost::thread, at least in my book.  Which helps our cause, but not that of the poor programmer.

Hans
> 
> -Howard
> 
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>