Subject: Re: [boost] [thread] to std:: or not to std::
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2012-12-25 07:48:39
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.
>>> 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
>>> 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
>> 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 :(
>> 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
>> 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.
-- View this message in context: http://boost.2283326.n4.nabble.com/thread-to-std-or-not-to-std-tp4640499p4640540.html Sent from the Boost - Dev mailing list archive at Nabble.com.