[thread] to std:: or not to std::
There seems to be a trend to migrate boost::thread to std::thread. Has there been consideration that perhaps the user community may not want this? There are differing opinions on threads (obviously) and recent breaking changes concern me. For example, the thread destructor now calling terminate instead of detach has made the upgrade to 1.52 more troublesome than it should have been. 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. The purpose of this email isn't to debate the merit of the Boost.Thread feature set but instead to understand the future direction of the library. Can Vicente or someone provide the intended road map or general plan for the library? Thanks! michael -- Michael Caisse ciere consulting ciere.com
I want to add my $0.02 Boost Thread is on the one hand one of the center pices of the Boost library as threading is very important part of many applications, on the other hand it is one of the libraries that had broken the interfaces, APIs semantics so many times that to be honest I'm not sure how can I recommend it for any organization or product to use. I remember that I had severe problems in one of my project because of some API that was broken between 1.33 and 1.35 and later (IIRC) 1.38 For this reason I had brought my own threading library for one of my projects that is sufficient subset of Boost.Thread but I at least know that it works as I expect. Now I'm quite surprised that terminate is used instead of detach... If I was continue to use Boost.Thread it would clearly broke one of my applications as I relay on this behavior at several points. So please... do us a favor - stop breaking Boost libraries. Boost developers tend to forget that there are actually users who relay on these libraries and they finally got stuck with prehistoric/unsupported boost versions. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/
________________________________ From: Michael Caisse <mcaisse-lists@ciere.com> To: boost@lists.boost.org Sent: Sunday, December 23, 2012 8:05 AM Subject: [boost] [thread] to std:: or not to std::
There seems to be a trend to migrate boost::thread to std::thread.
Has there been consideration that perhaps the user community may not want this? There are differing opinions on threads (obviously) and recent breaking changes concern me.
For example, the thread destructor now calling terminate instead of detach has made the upgrade to 1.52 more troublesome than it should have been.
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.
The purpose of this email isn't to debate the merit of the Boost.Thread feature set but instead to understand the future direction of the library.
Can Vicente or someone provide the intended road map or general plan for the library?
Thanks! michael
-- Michael Caisse ciere consulting ciere.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Artyom Beilis wrote
I want to add my $0.02
Boost Thread is on the one hand one of the center pices of the Boost library as threading is very important part of many applications, on the other hand it is one of the libraries that had broken the interfaces, APIs semantics so many times that to be honest I'm not sure how can I recommend it for any organization or product to use.
I remember that I had severe problems in one of my project because of some API that was broken between 1.33 and 1.35 and later (IIRC) 1.38
For this reason I had brought my own threading library for one of my projects that is sufficient subset of Boost.Thread but I at least know that it works as I expect.
Now I'm quite surprised that terminate is used instead of detach...
If I was continue to use Boost.Thread it would clearly broke one
of my applications as I relay on this behavior at several points.
So please... do us a favor - stop breaking Boost libraries.
Boost developers tend to forget that there are actually users who relay on these libraries and they finally got stuck with prehistoric/unsupported boost versions.
This is not my case. I have taken in consideration the users and provide a smooth transition for them. Maybe my approach was wrong, but not my intention. Best, 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.
Michael Caisse-3 wrote
There seems to be a trend to migrate boost::thread to std::thread.
Yes, this is my inention.
Has there been consideration that perhaps the user community may not want this? There are differing opinions on threads (obviously) and recent breaking changes concern me.
For example, the thread destructor now calling terminate instead of detach has made the upgrade to 1.52 more troublesome than it should have been.
The breaking change was announced in 1.50, and it should take place on 1.53. Un Maybe I should make the announce more visible. Apologies.
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.
The purpose of this email isn't to debate the merit of the Boost.Thread feature set but instead to understand the future direction of the library.
Can Vicente or someone provide the intended road map or general plan for the library?
My intention is to provide an interface that conforms to the std thread library. And build on top of this whatever is needed to respond to the user expectations. I have tried to introduce the changes letting the users to migrate to the new interface/behavior (3 releases) but it seem sthis is not the way to introduce changes :( Version 1.53 introduces these breaking changes: "Breaking changes when BOOST_THREAD_VERSION==3 (Default value since Boost 1.53): There are some new features which share the same interface but with different behavior. These breaking features are provided by default when BOOST_THREAD_VERSION is 3, but the user can however choose the version 2 behavior by defining the corresponding macro. As for the deprecated features, these broken features will be only available until boost 1.55. #6229 C++11 compliance & Breaking change: Rename the unique_future to future following the c++11. #6266 C++11 compliance & Breaking change: thread destructor should call terminate if joinable. #6269 C++11 compliance & Breaking change: thread move assignment should call terminate if joinable. " If these chages are not desired we can just set the default BOOST_THREAD_VERSION==2 and take the time to discuss of a better way to move to the direction I had in mind. Best, 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.
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.
The purpose of this email isn't to debate the merit of the Boost.Thread feature set but instead to understand the future direction of the library.
Can Vicente or someone provide the intended road map or general plan for the library?
My intention is to provide an interface that conforms to the std thread library. And build on top of this whatever is needed to respond to the user expectations.
I have tried to introduce the changes letting the users to migrate to the new interface/behavior (3 releases) but it seem sthis is not the way to introduce changes :(
<snip>
If these chages are not desired we can just set the default BOOST_THREAD_VERSION==2 and take the time to discuss of a better way to move to the direction I had in mind.
Vicente - I appreciate very much that you have taken up maintenance of this library. I have not been very involved in the ML this past year and should have been paying closer attention. My personal concern is that I don't want a std::thread library. I already have that if I need it. I know this isn't the case for everyone and I understand the value of having a boost::std_thread. I know that some very smart people worked on std::thread, but I don't agree with all of their choices and prefer the behaviour and features of boost::thread in many cases. Perhaps defining BOOST_THREAD_VERSION is all I need to do. It might have been nice to branch the library so we have boost::thread and boost::std_thread... (just thinking out loud, I'm not wanting to recommending an increase in maintenance headache). Do you plan on removing extensions to std behaviour (such as interruption points) or just making existing behaviour conform to std when they differ? Take care - michael -- Michael Caisse ciere consulting ciere.com
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.
The purpose of this email isn't to debate the merit of the Boost.Thread feature set but instead to understand the future direction of the library.
Can Vicente or someone provide the intended road map or general plan for the library?
My intention is to provide an interface that conforms to the std thread library. And build on top of this whatever is needed to respond to the user expectations.
I have tried to introduce the changes letting the users to migrate to the new interface/behavior (3 releases) but it seem sthis is not the way to introduce changes :(
<snip>
If these chages are not desired we can just set the default BOOST_THREAD_VERSION==2 and take the time to discuss of a better way to move to the direction I had in mind.
Vicente -
I appreciate very much that you have taken up maintenance of this library. I have not been very involved in the ML this past year and should have been paying closer attention.
My personal concern is that I don't want a std::thread library. I already have that if I need it. I know this isn't the case for everyone and I understand the value of having a boost::std_thread.
I know that some very smart people worked on std::thread, but I don't agree with all of their choices and prefer the behaviour and features of boost::thread in many cases. Perhaps defining BOOST_THREAD_VERSION is all I need to do. It might have been nice to branch the library so we have boost::thread and boost::std_thread... (just thinking out loud, I'm not wanting to recommending an increase in maintenance headache).
I didn`t considered this alternative, and may be I should. It was an evidence for me that people wanted a Boost.Thread library that behaves as the standard one and provide additional features. It seems that I was wrong.
Do you plan on removing extensions to std behaviour (such as interruption points) or just making existing behaviour conform to std when they differ?
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. Best, 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.
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. 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..) So please, do not make Boost.Thread a "one size fits all" solution as then it probably suits nobody's needs. -- Pekka
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-tp4640499p464... Sent from the Boost - Dev mailing list archive at Nabble.com.
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
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.
participants (4)
-
Artyom Beilis -
Michael Caisse -
Pekka Seppänen -
Vicente Botet