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
>>> 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
>>> extracted (and duplicated) interruption_handle.
>> Please, could you elaborate which part of the Boost.Thread interface are
>> using that the std interface don`t provides?
>>> I doubt I'll ever be able to do that trick with any std implementation,
>>> have to re-invent the wheel and supply my own thread implementation. I
>>> 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
>>> is considered..)
>> I don`t know what do you need exactly. What about making an explicit
>>> So please, do not make Boost.Thread a "one size fits all" solution as
>>> 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
> see Boost.Thread that has more features and thus is less std compiliance
> the other way around.
> So at least please don't drop any current features on a bases that they
> not present on the current standard. I don't see any reason why
> should be a drop in replacement for the std interface as we'll eventually
> some basic implementations that'll ship with the compilers.
> With the exploited timed_join< .. >() example I tried to eleborate that
> 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.
-- 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk