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 06:55:06

On 27.12.2012 13:07, Vicente Botet wrote:
>> 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.

What I meant was that the std interface doesn't offer too much and I'd rather
see Boost.Thread that has more features and thus is less std compiliance than
the other way around.

So at least please don't drop any current features on a bases that they are
not present on the current standard. I don't see any reason why Boost.Thread
should be a drop in replacement for the std interface as we'll eventually see
some basic implementations that'll ship with the compilers.

With the exploited timed_join< .. >() example I tried to eleborate that just
having your threads to start and stop really isn't enough unless you're
building some trivial programs. Perhaps I could submit a patch that would
provide a public member function to get native interruption handle; again
something that a std interface won't have for ages if ever.

Don't fix it if it ain't broken; and I don't think Boost.Thread is broken at
the moment (though I didn't like the std::terminate dtor thingy, does more
harm than good).

-- Pekka