On 25.12.2012 14:48, Vicente Botet wrote:
Michael Caisse-3 wrote
On 12/24/2012 03:34 AM, Vicente Botet wrote:
Michael Caisse-3 wrote
There seems to be a trend to migrate boost::thread to std::thread.
Yes, this is my inention.
<snip>
Will the next move be to remove interruption points? We have purposely selected Boost.Thread on a few projects that are also using C++11 because we prefer the Boost.Thread behaviour and feature set.
<snipety snip>
I think that it will be great to have interruptibles and non interruptible threads. For the time been I have just made it possible to have one of both, as some people considered the everhead not justified. I am on the phase of seen how both can be provided on the same executable. Of course this will need two different classes. I will start a new thread when I will have something more concrete.
Btw, I exploit timed_join< .. >() to extract interruption_handle from the private thread_info member. A real killer as some Win32 APIs provide messaging/events via native handles so there's no need for busy waiting/polling as you can break from the WaitForMultipleObjects() using the extracted (and duplicated) interruption_handle. I doubt I'll ever be able to do that trick with any std implementation, so I'd have to re-invent the wheel and supply my own thread implementation. I think this is the reason why you can't std everything: Too many real life applications need to use the tricks that your OS has to offer. (I guess you could have a "third wheel" thread to watch over the another threads and do the OS event signaling, but again, why especially if overhead is considered..) So please, do not make Boost.Thread a "one size fits all" solution as then it probably suits nobody's needs. -- Pekka