Re: [boost] [thread] to std:: or not to std::

Subject: Re: [boost] [thread] to std:: or not to std::
From: Pekka Seppänen (pekka.seppanen_at_[hidden])
Date: 2012-12-27 02:44:37

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