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

Subject: Re: [boost] [thread] to std:: or not to std::
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2012-12-27 06:07:48

Pekka Seppänen-2 wrote
> 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.

Please, could you elaborate which part of the Boost.Thread interface are you
using that the std interface don`t provides?

> 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..)

I don`t know what do you need exactly. What about making an explicit feature
request?
  

> So please, do not make Boost.Thread a "one size fits all" solution as then
> it
> probably suits nobody's needs.

Could you tell me how I`m making Boost.Thread a "one size fits all"
solution? This could help me to avoid it.

Best,
Vicente 

--
View this message in context: http://boost.2283326.n4.nabble.com/thread-to-std-or-not-to-std-tp4640499p4640609.html
Sent from the Boost - Dev mailing list archive at Nabble.com.