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-tp4640499p464... Sent from the Boost - Dev mailing list archive at Nabble.com.