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 14:56:01

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

I`d appreciate if you describes your needs so that we can analyze the best
way to manage with they.
  
Vicente

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